Comment by btrask
10 years ago
Thanks for this comment. It's the first really substantiative response to my core thesis.
I don't think the math is on your side. As the defect rate approaches zero, there are diminishing returns to pushing it lower. On the other hand, the attack surface effect becomes overwhelming. Addressing both at once will be far more effective than concentrating on one or the other.
You might be right that in the long run, the defect rate needs to be 0.0. But that is a long ways away. Once we've picked the low-hanging fruit (including perhaps a provably correct sandbox), then we can start thinking about how to prove the correctness of random applications.
> I don't think the math is on your side. As the defect rate approaches zero, there are diminishing returns to pushing it lower. On the other hand, the attack surface effect becomes overwhelming. Addressing both at once will be far more effective than concentrating on one or the other.
Huh? That's not how it works, is it? If we want to minimize X * Y and we currently have X = 50 and Y = 5, it's much more efficient to focus on bringing Y down.
> Once we've picked the low-hanging fruit (including perhaps a provably correct sandbox), then we can start thinking about how to prove the correctness of random applications.
"low-hanging fruit" tends to mean doing unprincipled things that can't be generalized / don't contribute anything in the long term, right? My view is that there's limited value in lowering the rate of security flaws in ways that aren't on the path to bringing it to zero. Getting it to zero will be valuable; halving it isn't really (there's some economic value in reducing the frequency of breaches, but not enough). So I don't think ad-hoc countermeasures are worthwhile.
To the extent to which a sandbox can be written in a principled/provable way it will be valuable. I'm not at all convinced that a general-purpose sandbox is possible, but that's a different question. (The techniques of factoring a program into pieces with the minimal capabilities that they need are valuable, but I think this needs to be done far more holistically than is possible with a sandbox; the security design needs to reflect the program design, because whether particular operations are safe or not is a function of the application-specific context. But this is very much speculation on my part)
> That's not how it works, is it? If we want to minimize X * Y and we currently have X = 50 and Y = 5, it's much more efficient to focus on bringing Y down.
I guess I see 0 as the asymptote. Like if you're already at 99.99% reliability, adding another 9 is quite hard. On the other hand, if you're at 10%, then there are big gains to be had.
> "low-hanging fruit" tends to mean doing unprincipled things that can't be generalized / don't contribute anything in the long term, right?
I think sandboxes generalize much better than application-specific proofs. Once you have a provably correct sandbox (which I think is possible today, if you exclude things like 3D acceleration), you can run whatever you want in it: old software, games, Flash, Windows 98. Application-specific proofs only work for applications written in the approved way.
> Once you have a provably correct sandbox (which I think is possible today, if you exclude things like 3D acceleration), you can run whatever you want in it: old software, games, Flash, Windows 98. Application-specific proofs only work for applications written in the approved way.
What would a generic sandbox enforce? That an application never accesses the network? That it never accesses the local filesystem? That it never communicates with another process? Browsers need to do all those things and more. I think you need application-specific knowledge to be able to enforce the restrictions that matter.
6 replies →
Quality specialist here who worked on testing Gecko platform targets for Mozilla for several years,
For anything halfway complex, you can't reasonably find all the bugs for precisely the same reason you can't reasonably get full path code coverage out of your tests. The possibilities around interactions (this is where bugs mostly live) scale very, very high as more components are involved. A simple example is that ten boolean flags or checkboxes that interact with each other--or, more accurately, possibly interact with each other, if you can't prove they don't--means 2^10 possible states to check. Most things don't just take two values. Add system-level and user-level non-determinism and good luck.
In quality, we handle this via testing by state equivalence, predicting how common a set of interactions will be and prioritizing accordingly, and other shortcut techniques meant to put a finite amount of effort around reducing risk to whatever won't sink your product, but it's almost impossible to reduce to zero. You have to spend a metric crapton of money to do it, which is why A) you mostly only see that kind of goal in stuff like aerospace and B) planes cost an awful lot.
I haven't even gotten to the part where you don't know all the possible defective side effects that could be there and probably wouldn't think to look for everything possible even if you theoretically could. Keep in mind that you're treating the application behavior as inherently untrustworthy, so you can't just assume you know how it'd fail either. For all you know it'll interact with an OS bug in a novel way. There are surprises everywhere.
The sandbox idea is a really good one because it means you can do this once, presumably in a system of controlled complexity architected in a way to be highly testable and highly reviewable. That's your best bet for getting near zero defects: high modularity with strict interfaces and limited interactions all of which are highly deterministic. You definitely won't get that with something as complex as an entire browser platform.
Making the job as small and easy as possible and only doing it once are probably the key here.