
DJB acknowledges vulnerability in djbdns; pays out the $1000 reward - dfranke
http://article.gmane.org/gmane.network.djbdns/13864
======
tptacek
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.

~~~
sfk
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. */

~~~
tptacek
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.

------
kurtosis
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?

~~~
tptacek
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.

------
jayp
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.

~~~
tptacek
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.

~~~
brl
> 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)

[http://www.ornl.gov/lists/mailing-
lists/qmail/2005/05/msg008...](http://www.ornl.gov/lists/mailing-
lists/qmail/2005/05/msg00838.html)

------
nikron
Nice 1 line patch... I'm surprised it could be fixed so easily.

~~~
cperciva
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.

------
newt0311
Now if only we could make software companies do something similar...

~~~
cperciva
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!)

