Comment by lmm
10 years ago
If we can get the defect rate down to zero, then the product of that and the attack surface will still be zero.
If we can't do that, how much will sandboxing help? Sure, we can make a much smaller surface that we expose - let's say 1% of the size of what the browser currently exposes. Will that be good enough though? Xen's surface is about as small as you can get for a reasonable general-purpose sandbox, and, per the article, Xen has a lot of vulnerabilities too.
I think the only option is to push the defect rate down to zero. (This may be impossible; if so, we're all going to die. Computing power will inevitably advance to the point where any vulnerable system can be cracked by a lone terrorist, and economics and our inability to coordinate ensure that power plants, water treatment facilities, automated bioengineering facilities etc. are going to be computerized.)
Rust is, I think, worthwhile as a step on the road towards provably correct programs - memory management isn't everything, but it's something. Sandboxing OTOH feels like a dead end, because it's inherently ad-hoc and unprincipled.
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.
7 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.