Slashdot Mirror
Dan Bernstein Confirms Security Flaw In Djbdns
secmartin writes "Dan Bernstein has just admitted that a security issue has been found in the djbdns software, one of most popular alternatives for the BIND nameserver. As part of the djbdns security guarantee, $1000 will be paid to Matthew Dempsky, the researcher that found the bug. The bug allows a nameserver running djbdns to be poisoned using just a single packet. Other researchers have found a separate issue that allows dnscache, the DNS cache that is also part of the djbdns package, to be poisoned within just 18 minutes when using the default configuration. Anyone using djbdns is strongly encouraged to patch their servers immediately."
Reader emad contributes a link to the djbdns mailing list post containing both a patch and a sample exploit, and adds: "In the words of Dan Kaminsky (of recent DNS security fame): 'However, Dempsky's bug in djb's tinydns is way more surprising, if only because ... holy crap, he pulled an exploitable scenario out of THAT?!'"
Why would anyone trust critical internet infrastructure to a piece of software that averages a security flaw every decade?
Real admins stick to a proven solution such as Bind.
DBJ admitted to a bug.
I run qmail by the way. DJB writes good stable software but I get the impression he is not a good listener.
http://michaelsmith.id.au
DJBDNS now has 1/3 as many exploits as OpenBSD for the past decade+.
How's Microsoft doing on that front?
Oh wait.
Finding a security flaw in anything Dan Bernstein writes is definitely worthy of being on the front page, even if almost everybody uses Bind instead.
Need a Python, C++, Unix, Linux develop
Since I'm one of the admins who's enjoyed having an vulnerability-free djbdns installation for years, I thought I'd look more into the vuln.
Say what you will about DJB, other than being seemingly ornery he appears to be forthright and focused on correctness. In under a week he confirms the vuln and posts a patch and awards the security guarantee money. This is the kind of behavior I want from the people who build my software. http://article.gmane.org/gmane.network.djbdns/13864
Here's the bug:
If the administrator of example.com publishes the example.com DNS data
through tinydns and axfrdns, and includes data for sub.example.com
transferred from an untrusted third party, then that third party can
control cache entries for example.com, not just sub.example.com.
How many of you are running domains like this? It's not something I need to bother patching for. Ah, I guess that's another great thing about the relative rarity of bugs. If one is found it's less likely to be relevant for your particular situation.
The article submitter says:
"Anyone using djbdns is strongly encouraged to patch their servers immediately."
I think "anyone" is a bit strong here.
I just realized this:
The next release of djbdns will be backed by a new security guarantee.
In the meantime, if any users are in the situation described above,
those users are advised to apply Dempsky's patch and requested to accept
my apologies.
He's apologizing. How's that for forthright behavior? He's not being evasive. He's not pointing fingers. He's owning up to personal error, and expressing what appears to be compunction. For one bug in a decade.
Yeah, tell me how you don't like his attitude. I think it's fine.
Mr. Bernstein, good work I say. Thank you very much for your efforts and skill and honesty.
How does Address Space Layout Randomization (ASLR) affect total memory usage and its implications for counter values?
4 GB per process is what they were talking about. Really, seems improbable to me. Isn't that a bit like too many coops in one basket?
First of all, I really like djbdns! Up until two weeks ago I ran it for our my employer (700~ tlds) and it had been running flawless for the last 4 years.
The reason, in the end, for the switch is due to the administrative workload of using djbdns.
Pushing updates to other servers usually involves pushing the .cdb data file to the dns/root directory of each of the resolves. Ok one chore, fine. The problem is in managing the database.
Managing 50-100 records command line is feasible, but if you have a lot of domain and turn over a lot of requests for modifications a day this quickly becomes a pain.
We built a script to store the records in a sql database then create the data file, create the cdb from that, then push the updated file across the network.
Our new dns server runs directly to the SQL db, provides solid query caching.. Now I just have to replicate a sql db which is comparatively pain-free :)
Not had my morning coffee yet so please pardon the grammar/seplling ;)
Add Linus while you're at it.
c++;
I had to check to make sure you weren't my old boss! A place I worked about a year ago did that. Our systems automatically registered hosted domain names and dropped the list of subdomains into our database. A cron job pulled records from there, generated the data file, compiled it and told tinydns to reload it.
I really appreciated djbdns's data format after having dealt with BIND at my last job. I remember it being disturbingly finicky about its input--there are plenty of ways to kill your DNS server if, for instance, you didn't increment the serial (why on earth doesn't it just use the timestamp in seconds?) or left out a period somewhere.
Laws do not persuade just because they threaten. --Seneca