I disagree with djb here: Although it's true that privilege separation rarely eliminates vulnerabilities, I maintain that it can make vulnerabilities far less dangerous.
To take an example the Capsicum people are fond of: Decompression. zlib has a long history of vulnerabilities in decompression of corrupt data, so it's a natural thing to run inside a sandbox. djb's argument is "but a vulnerability in zlib is still bad because it can return incorrect output", which is true as far as it goes, but it completely misses the important point that it prevents the attacker from accessing anything not inside zlib's sandbox -- say, connections to a database.
I think Dan Bernstein is an absolutist, in the sense that he believes error-free ("invulnerable") programs are commercially achievable. I don't agree, but I think his perspective sheds some pretty valuable light.
I'm somewhere between the two of you: I think error-free programs are achievable, but I realize it's a huge amount of work and it's impossible to ever know for certain if you've succeeded. I see capsicum as something to help bridge the gap between "I don't think there are any bugs in here" and "this program is safe to run".
Diagonal proofs like the Halting Problem say that in general you can not prove properties about all programs in a Turing complete language. Thus, there is a class of troublesome programs.
Likewise there is obviously a great number of programs in Turing complete languages that you can prove properties about. Thus, there is a class of pleasant programs (or [program, property] pairs).
We do not know for certain how many of the programs that we want to write that is in each class. I would venture a guess that >99% of all programs ever written are in the "nice" class. If it is really impossible to reason about some property of a program, why would you think it works?
Another important point is that the attacker already has the ability to affect the decompressed output, since they are presumably responsible for the compressed input.
Depending on how you set things up you might use one sandbox to perform multiple decompression calls, so the attacker might be able to mangle someone else's data. But yes, if you set up a new sandbox for each inflate you're safe.
> "but a vulnerability in zlib is still bad because it can return incorrect output" which is true as far as it goes, but it completely misses the important point that it prevents the attacker from accessing anything not inside zlib's sandbox -- say, connections to a database.
Wouldn't being able to impact the output of zlib decompression also impact whatever is subsequently working on that output next though (just 'moving the goalpost')?
Comments
I disagree with djb here: Although it's true that privilege separation rarely eliminates vulnerabilities, I maintain that it can make vulnerabilities far less dangerous.
To take an example the Capsicum people are fond of: Decompression. zlib has a long history of vulnerabilities in decompression of corrupt data, so it's a natural thing to run inside a sandbox. djb's argument is "but a vulnerability in zlib is still bad because it can return incorrect output", which is true as far as it goes, but it completely misses the important point that it prevents the attacker from accessing anything not inside zlib's sandbox -- say, connections to a database.
I think Dan Bernstein is an absolutist, in the sense that he believes error-free ("invulnerable") programs are commercially achievable. I don't agree, but I think his perspective sheds some pretty valuable light.
I'm somewhere between the two of you: I think error-free programs are achievable, but I realize it's a huge amount of work and it's impossible to ever know for certain if you've succeeded. I see capsicum as something to help bridge the gap between "I don't think there are any bugs in here" and "this program is safe to run".
Classical example of "you never know for certain if you've succeeded": http://en.wikipedia.org/wiki/IEFBR14#History_from_the_RISKS_... (see also the takk page and the refernced http://www.miketaylor.org.uk/tech/oreilly/iefbr14.html for some comments on the veracity of these statements)
There's always the great ivory tower known as Provable Programming.
Provable Programming provably requires non-Turing-complete languages.
Which isn't an insuperable barrier, to be sure, but it's a big piece of evidence against its practicality in actual commercial environments.
why has this been downvoted? if this is wrong, a simple "no, this is wrong. see e.g. blah" would have been nice.
Diagonal proofs like the Halting Problem say that in general you can not prove properties about all programs in a Turing complete language. Thus, there is a class of troublesome programs.
Likewise there is obviously a great number of programs in Turing complete languages that you can prove properties about. Thus, there is a class of pleasant programs (or [program, property] pairs).
We do not know for certain how many of the programs that we want to write that is in each class. I would venture a guess that >99% of all programs ever written are in the "nice" class. If it is really impossible to reason about some property of a program, why would you think it works?
Another important point is that the attacker already has the ability to affect the decompressed output, since they are presumably responsible for the compressed input.
Depending on how you set things up you might use one sandbox to perform multiple decompression calls, so the attacker might be able to mangle someone else's data. But yes, if you set up a new sandbox for each inflate you're safe.
Hash the decompressed data and check the result returned by zlib.