Wow, I believe this is the first-ever "security guarantee" payout by DJB? Not bad!, not bad at all!, considering how popular both qmail and djbdns are.
I think so, unless you count the prize for "most interesting cryptanalysis of Salsa20" as a security guarantee. Also, someone discovered a bug in qmail a while back, but DJB disputed that it was security-related and didn't pay. Having seen the details, I'm inclined to side with DJB.
There was a (contested) claim against qmail, where Georgi Guninski found an LP64 integer overflow that would only have been exploitable if you explicitly configured your system to allow qmail to consume huge amounts of memory. The code was imperfect, but the deployed software was safe. So far as I know, DJB didn't pay this out. I'm ambivalent about it.
would only have been exploitable if you explicitly configured your system to allow qmail to consume huge amounts of memory.
Are you sure it's explicit (ie: changing some qmail configuration file) rather than just depending on how the system-wide rlimits are set up?
Guninski claimed that following the exact instructions in the INSTALL file results in a vulnerable configuration (assuming the exploitable hardware configuration)
The cash rewards always really turned me off from DJB - it sounded like borderline crackpot behavior. The fact that he actually paid it out instantly puts all doubts to rest about his seriousness. I'm of course a long time fan of qmail and djbdns daemontools etc..
I understand his motivation to provide incentives for people to find bugs in his software. Question: how do you provide incentives for people to break your system and report it to you without sounding like a crackpot, other than hiring them?
I think most non-security people have roughly the same initial reaction as you did; it sounded silly, especially because lots of commercial enterprises have offered "security guarantees" and held "hacking contests" and weaseled at the results.
I know most security people don't care about the guarantee. We try to beat up on DJB's software because it is so hard to find security flaws in it, everyone knows that, and so a finding is a major reputation win. Nobody cares about the $1000; that's significantly less than a day's bill rate for the class of researcher that is likely to find these flaws.
The moral of this story is, don't bother with the guarantee:
(1) You will end up being asked to pay it out, because you are not Daniel J. Bernstein, and you will not write software as solid as qmail.
(2) It isn't going to impress anyone you care about.
(3) It isn't going to motivate hard-core researchers.
Offering prize money for discovering flaws is point #13 on the crackpot index (http://math.ucr.edu/home/baez/crackpot.html). I've griped in the past that this criterion is too prone to false positives, citing DJB as an example.
Names in DNS packets are "compressed" by encoding repeated labels ("google.com" in a Google A query) as offsets to the first place in the packet the label was seen. The offset encoding allows 14 bits for the actual integer.
Dempsky's bug causes DJB's code to attempt to compress a name whose suffix is first seen more than 16384 bytes into the packet, which rolls that counter, which throws off the rest of the parse and allows data that should be junk inside a record to instead be parsed as a seperate record.
This is the second integer-related security flaw in DJB's code (and apparently the first exploitable one). Integer handling in C code is hard to get right; there are lots of corner cases, but more importantly there are lots of sites in your code you have to check at, unlike buffer overflows, which are almost always sited at your (relatively infrequent) buffer copies.
It has also been a historic source of both security flaws (BIND's problems with DNS compression were remote code execution flaws, not baroque policy violations in delegated subdomains) and interoperability failures (BIND has been unable to decide which record contents are compressable versus which ones need to remain canonical).
But yeah, the experts in this protocol should definitely be the ones to design an Internet-wide PKI.
This is the second integer-related security flaw in DJB's code (and apparently the first exploitable one).
Here is what DJB has to say about the exploitability of Guninski's bug:
"In May 2005, Georgi Guninski claimed that some
potential 64-bit portability problems allowed
a ``remote exploit in qmail-smtpd.'' This claim
is denied. Nobody gives gigabytes of memory to
each qmail-smtpd process, so there is no problem
with qmail's assumption that allocated array
lengths fit comfortably into 32 bits. "
I'm not sure I'm convinced by this line of reasoning :)
Wow, I believe this is the first-ever "security guarantee" payout by DJB? Not bad!, not bad at all!, considering how popular both qmail and djbdns are.
I think so, unless you count the prize for "most interesting cryptanalysis of Salsa20" as a security guarantee. Also, someone discovered a bug in qmail a while back, but DJB disputed that it was security-related and didn't pay. Having seen the details, I'm inclined to side with DJB.
There was a (contested) claim against qmail, where Georgi Guninski found an LP64 integer overflow that would only have been exploitable if you explicitly configured your system to allow qmail to consume huge amounts of memory. The code was imperfect, but the deployed software was safe. So far as I know, DJB didn't pay this out. I'm ambivalent about it.
Are you sure it's explicit (ie: changing some qmail configuration file) rather than just depending on how the system-wide rlimits are set up?
Guninski claimed that following the exact instructions in the INSTALL file results in a vulnerable configuration (assuming the exploitable hardware configuration)
http://www.ornl.gov/lists/mailing-lists/qmail/2005/05/msg008...
Now if only we could make software companies do something similar...
I'm planning on doing this for tarsnap once it leaves beta. (Well, offering a guarantee -- I hope I'll never have to pay up!)
The cash rewards always really turned me off from DJB - it sounded like borderline crackpot behavior. The fact that he actually paid it out instantly puts all doubts to rest about his seriousness. I'm of course a long time fan of qmail and djbdns daemontools etc.. I understand his motivation to provide incentives for people to find bugs in his software. Question: how do you provide incentives for people to break your system and report it to you without sounding like a crackpot, other than hiring them?
Have a reputation. Nobody who is qualified to review djb's code is going to get him confused with a crackpot.
I don't think the guarantee was a win.
I think most non-security people have roughly the same initial reaction as you did; it sounded silly, especially because lots of commercial enterprises have offered "security guarantees" and held "hacking contests" and weaseled at the results.
I know most security people don't care about the guarantee. We try to beat up on DJB's software because it is so hard to find security flaws in it, everyone knows that, and so a finding is a major reputation win. Nobody cares about the $1000; that's significantly less than a day's bill rate for the class of researcher that is likely to find these flaws.
The moral of this story is, don't bother with the guarantee:
(1) You will end up being asked to pay it out, because you are not Daniel J. Bernstein, and you will not write software as solid as qmail.
(2) It isn't going to impress anyone you care about.
(3) It isn't going to motivate hard-core researchers.
Offering prize money for discovering flaws is point #13 on the crackpot index (http://math.ucr.edu/home/baez/crackpot.html). I've griped in the past that this criterion is too prone to false positives, citing DJB as an example.
Nice 1 line patch... I'm surprised it could be fixed so easily.
Small security patches aren't uncommon -- offhand, I'd guess that about 75% of FreeBSD security advisories are fixed by patches of 5 lines or less.
Wondering what the flaw was?
Names in DNS packets are "compressed" by encoding repeated labels ("google.com" in a Google A query) as offsets to the first place in the packet the label was seen. The offset encoding allows 14 bits for the actual integer.
Dempsky's bug causes DJB's code to attempt to compress a name whose suffix is first seen more than 16384 bytes into the packet, which rolls that counter, which throws off the rest of the parse and allows data that should be junk inside a record to instead be parsed as a seperate record.
This is the second integer-related security flaw in DJB's code (and apparently the first exploitable one). Integer handling in C code is hard to get right; there are lots of corner cases, but more importantly there are lots of sites in your code you have to check at, unlike buffer overflows, which are almost always sited at your (relatively infrequent) buffer copies.
As an aside, the official "compression" algorithm is just unbelievable. DJB's comment in dns_packet.c is quite apt:
/* DNS should have used LZ77 instead of its own sophomoric compression algorithm. */
It has also been a historic source of both security flaws (BIND's problems with DNS compression were remote code execution flaws, not baroque policy violations in delegated subdomains) and interoperability failures (BIND has been unable to decide which record contents are compressable versus which ones need to remain canonical).
But yeah, the experts in this protocol should definitely be the ones to design an Internet-wide PKI.
Here is what DJB has to say about the exploitability of Guninski's bug:
I'm not sure I'm convinced by this line of reasoning :)