DJB acknowledges vulnerability in djbdns; pays out the $1000 reward
article.gmane.org
article.gmane.org
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.
/* DNS should have used LZ77 instead of its own sophomoric compression algorithm. */
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:
"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 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.
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...