Support this website
One issue with making software is that a responsible programmer takes responsibility for his mistakes. Even if the mistakes were made years ago. MaraDNS is a lot of code dating back to 2001; even though a good deal of the code has been completely rewritten, I still take responsibility for code I wrote in 2001 and 2002.

I very strongly encourage people still using MaraDNS 1.x's recursive code to upgrade to MaraDNS 2, and use Deadwood to process recursive queries. I have completely rewritten the code from the ground up -- Deadwood shares no code whatsoever with MaraDNS -- and did a better job of it the second time around.

The new Deadwood recursive resolver, for example, has been using randomized hashes since 2007, and today's hash randomization attack making the rounds has never affected Deadwood. The older MaraDNS 1.x recursive code, however, did not use a randomized hash. While people really should be using Deadwood for recursive queries, I have released MaraDNS 1.4.08 and MaraDNS 1.3.07.12 with an updated randomized hash.

For anyone who is still using MaraDNS 1, it is important to upgrade to this version in order so that hashes are randomized and not vulnerable to hash collision denial of service attacks. Or better yet, upgrade to MaraDNS 2.

Note that a randomized hash needs a source of entropy; that in mind, the *NIX version of MaraDNS 1.4.08/1.3.07.12 requires /dev/urandom and the Windows version of MaraDNS needs "secret.txt" in the same directory as "maradns.exe". People running MaraDNS 1 on *NIX systems without /dev/urandom are on their own -- I do not support MaraDNS on anything besides CentOS, Scientific Linux, and Windows.

Note that this security bug only affects you if:

• You are using MaraDNS 1, *not* MaraDNS 2
• recursive_acl is set in MaraDNS 1
• Untrusted potential attackers can perform recursive queries with MaraDNS 1.

For example, if using MaraDNS 1 as described in http://samiam.org/blog/20111128.html, one is safe as long as ones mararc file recursive_acl line looks like this:

recursive_acl = "127.0.0.1/8"

The tarballs files can be found here:

http://maradns.org/download/1.3

http://maradns.org/download/1.4 (also has Windows binary)

The patch is here:

http://maradns.org/download/patches/maradns-1.3-secret_hash.patch

No, MaraDNS 2.0's authoritative server does not use a randomized hash. No, this is not a problem because a remote attacker can not control the hash keys. Yes, this could be an issue if an untrusted attacker were able to control MaraDNS' zone files, but that is a much smaller attack surface. I will fix this in MaraDNS 2.0, but only once Deadwood 3.2 is out the door next year.

To post a comment about an entry, send me an email and I may or may not post your comment (with or without editing)