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.
Comments
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.
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.
Also, I miss you.
"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.
You misspelled zarro. :-|
I miss Justin too!
/be
I miss you too.