Miron's Weblog

I’ve been asked to outline specific scenarios after I posted a previous entry on the Google’s network compromise.  Here are some, from most serious to least serious:

• Build host – the machines that compile the source into binary packages are compromised.  In this scenario, code can be injected by the malicious party into the package just before it is signed and prepared for distribution.  All clients that install the updated packages are affected.  A software audit cannot identify the altered packages because the alteration happens after binaries are generated.
• Distribution host and Signing key – the machines that host the packages for distribution (web servers) are compromised and the package signing key is compromised.  The effect of this is the same as a build host compromise.
• Source repository – the machines that host the software source-code are compromised.  This allows code to be injected and all clients are affected.  However, a software audit can uncover the injected code.
• Insider threats – an insider can insert non-obvious security holes into software they are responsible for.
• Signing key – the key used to sign the software distribution is compromised.  This would allow the malicious party to compromise only specific targeted clients through a “man-in-the-middle” attack and DNS poisoning

How would multiple independent auditors help?  If the auditors can verify that a binary was produced from certain source, the build host compromise would be much harder, since the altered binary would not signed by the uncompromised auditors.  Similarly, a signing key compromise, if it is limited to a subset of auditors, would fail to get a full set of signatures on the altered package.

Source repository compromise and Insider injection of security holes would be more difficult to detect for subtle exploits, but again, multiple entities looking at the code increases the chances that the alteration would be caught.

(Note: verification that a certain binary was produced from certain source code requires a deterministic build system. Although such a system is relatively straightforward to implement, I have not run across one before I implemented Gitian.  I did find mention of it by Conifer Systems.)

Tags: Secure Software // 1 Comment »

Operation Aurora (Google’s compromise by China) highlights the possibility that software distributions may be targeted for code injection by malicious parties.  If Apple, Microsoft or a linux distributors are compromised, a large percentage of individuals, businesses and governments could be consequentially compromised when they install software updates.

One way to mitigate such a risk is to have multiple independent security auditors sign software distributions.  This is more likely to be successful in an open-source environment, where source is available and can easily be inspected.  I started such an initiative in late 2009 – Gitian.org.

Tags: Secure Software // 4 Comments »