This is good and necessary, but I see this as mostly symbolic. In practical terms, coercing a browser vendor into modifying their binaries to add an exploit is a comparatively risky and difficult way for the NSA to get a backdoor. There are much less-risky ways for the NSA to get an exploit. To wit:
1) All browser vendors keep a private catalog of security-critical bugs. If the NSA cared to gain access to these, they could, with or without the cooperation of the vendor.
2) The NSA maintains its own catalog of zero-days in browsers, operating systems, Flash, Acrobat, and so on. They actively exploit these bugs in attacks targeted against individuals. That these attacks are delivered only to their intended targets makes the bugs essentially impossible for browser developers to detect and fix, until they're independently discovered.
3) NSA can add exploits to source. Compared to coercing a vendor into adding an exploit into their binaries, this has the advantage of being easy to pull off without the vendor's knowledge or cooperation.
In terms of Firefox specifically, the safeguards in place are not sufficient to prevent a determined adversary from committing a backdoor into the source. Code review can't catch all security-critical bugs, and anyway Mozilla committers regularly check in code which doesn't match the reviewed code; it would be easy to slip in an exploit after review.
I suspect something similar applies to other browsers. A browser's being OSS only makes the NSA's job of adding exploits marginally easier; there's nothing stopping the NSA from planting engineers on the IE team, for example.
4) The NSA could use its targeted attack ability to deliver backdoored binaries to specific targets. Even if Mozilla protects downloads with a pinned SSL cert, I have to believe that stealing or forging a cert is not out of the question for the NSA.
If I were the NSA, I'd need to observe that none of the above strategies was working before attempting the much more risky job of coercing a browser vendor into adding an exploit into the binaries they distribute. And we know that at least (2) above /is/ working for the NSA.
In other words, if we're serious about securing our browsers against this adversary, we need to think a lot bigger than just verifying that the binaries on our FTP servers match our source.
Auditing != code review. Static analysis and fuzzing count as auditing in general (and fuzzing works on closed source too).
@cromwellian's citation of Snowden on weak endpoint (OS, PCs running Windows especially) security is on target. Security is never done, and there are too many levels and spots to attack for users, open source projects, and even big companies to be able to afford defense everywhere. (Get a load of https://www.openssl.org/news/secadv_hack.txt if you haven't seen it.)
The browser cannot be excluded from this analysis. It presents a large attack surface, and top browsers have wide unverified binary distribution nets.
Adding exploits to Linux open source has been attempted but detected. We don't of course know of undetected successful attempts.
The risk of coercing a browser vendor is hard to quantify. Ladar Levison of Lavabit was brave enough to speak up pre-gag-order and shut down his business.
Have the principals of other companies been that tough? We don't know in some cases, but in others the answer is "no".
Even excluding what some such company principals didn't know but should have known (oops, unencrypted data over telco dark fiber), the bigs knew enough pre-Snowden to make a public stink. None did; many (AT&T, e.g. -- there are other examples) were complicit for decades.
Regarding #1 & #2: We need to find a way to drastically reduce (literally to zero) exploitable defects. Browsers, and especially Firefox, can go a lot farther here than they historically have. In the case of Firefox in particular, we'll figure out a way to make sandboxing work for Gecko and there's good reason to expect that Servo can succeed. But, even sandboxing and memory-safe languages cannot prevent logic problems. For example, https://bugzilla.mozilla.org/show_bug.cgi?id=919877 is up there as one of the worst SSL implementation bugs of all time, and Chrome's sandboxing did nothing to stop it, and neither would using a memory-safe language. (Edit: that bug never affected any Firefox release, as we found & fixed the bug before enabling that feature in the upcoming Firefox 28.) Ultimately, openness, and the verifiability that bolsters it, will be essential for getting to zero security vulnerabilities no matter what defense-in-depth mechanisms we put in place.
RE #3: I don't think the NSA even needs to try this yet, given #1 and #2. There are too many vulnerabilities going into browsers accidentally for anybody to bother deliberately adding one.
Re #4: On Windows, SSL is a defense-in-depth measure for protecting Firefox downloads/updates. Windows's Authenticode check is another defense-in-depth measure. I agree that both aren't perfect, but they aren't completely useless. More importantly, though, Firefox updates on Windows are signed and verified using a mechanism that is completely separate from the public PKI world. This is the primary defense (IMO) and this is something we should extend to updates on other platforms. (B2G has its own, different, wholly-separate signing mechanism too.) The design is sound though I wouldn't be surprised if there were things we could do operationally to improve things further; I don't know since I'm not in opsec.
> In other words, if we're serious about securing our browsers against this adversary, we need to think a lot bigger than just verifying that the binaries on our FTP servers match our source.
I don't think that anybody is going to disagree with this. However, this statement being true doesn't mean that verifiable, open-source builds are useless. Especially in the long term, as we improve in #1 and #2 in particular, verifiability and openness is very important.
"But, even sandboxing and memory-safe languages cannot prevent logic problems."
=> Indeed. I wonder how you plan to reduce the amount of exploitable bugs to literally zero given that nothing can fully prevent logic problems.
Anyway, it sounds like a lot of work to reduce to literally zero the number of exploitable defects. Some advocate that a lazier approach based on POLA and object capabilities could work too.
https://www.youtube.com/watch?feature=player_detailpage&v=eL... (I timestamped for the relevant part, but the full talk is good to watch too).
Building on an object capability language, even if some exploitable bugs remain along the edges, allow a high-level of security. Not sure how Rust stands, but it looks promising for sure.
It works because a reviewer will say "here are a bunch of comments, the patch is approved once these are fixed". It's a very reasonable thing to say when the comments are minor (such a style issues) and the reviewer and coder trust each other.
Reviews are required, but we don't have automation to test integrity and authenticity. Mostly the diffs between what is reviewed and what is pushed are cosmetics that the reviewer asked for and pre-r+'ed without wanting another patch in a bug, but there's room for mischief.
People do watch bugs and repos and catch stuff. We are working on making the system more foolproof, as part of a larger effort to move all our CI infra (save Mac, sigh) to the cloud and our release engineering to a devops model.
1) All browser vendors keep a private catalog of security-critical bugs. If the NSA cared to gain access to these, they could, with or without the cooperation of the vendor.
2) The NSA maintains its own catalog of zero-days in browsers, operating systems, Flash, Acrobat, and so on. They actively exploit these bugs in attacks targeted against individuals. That these attacks are delivered only to their intended targets makes the bugs essentially impossible for browser developers to detect and fix, until they're independently discovered.
3) NSA can add exploits to source. Compared to coercing a vendor into adding an exploit into their binaries, this has the advantage of being easy to pull off without the vendor's knowledge or cooperation.
In terms of Firefox specifically, the safeguards in place are not sufficient to prevent a determined adversary from committing a backdoor into the source. Code review can't catch all security-critical bugs, and anyway Mozilla committers regularly check in code which doesn't match the reviewed code; it would be easy to slip in an exploit after review.
I suspect something similar applies to other browsers. A browser's being OSS only makes the NSA's job of adding exploits marginally easier; there's nothing stopping the NSA from planting engineers on the IE team, for example.
4) The NSA could use its targeted attack ability to deliver backdoored binaries to specific targets. Even if Mozilla protects downloads with a pinned SSL cert, I have to believe that stealing or forging a cert is not out of the question for the NSA.
If I were the NSA, I'd need to observe that none of the above strategies was working before attempting the much more risky job of coercing a browser vendor into adding an exploit into the binaries they distribute. And we know that at least (2) above /is/ working for the NSA.
In other words, if we're serious about securing our browsers against this adversary, we need to think a lot bigger than just verifying that the binaries on our FTP servers match our source.