==Two bugs in Deadwood fixed==
Sten Kultakangas pointed out that MaraDNS sends the wrong ID when sending a SERVER FAIL message. After working with him to recreate the bug, and an hour of hunting, I have determined this is not a security bug.
Deadwood takes the DNS packet it gets, performs some sanity checks on it, changes its ID and RD bit, and then sends it to the upstream server. This is fine in normal usage.
However, in the unusual case of giving a SERVER FAIL back to the calling DNS thingy (because of high load, etc.), it sends back the packet it sent upstream instead of sending back the packet the DNS thingy sent Deadwood, causing the query ID mismatch.
When looking over this bug, I found another bug: If there is a glueless NS record, Deadwood starts processing the NS referral, but sends a server fail to the DNS thingy (instead of sending nothing until the NS record is worked out).
I have also fixed this bug.
==Statement on CERT VU#264212==
Deadwood (MaraDNS 2.0) might be vulnerable. That in mind, I have made a new MaraDNS snapshot release with some code added to harden Deadwood against CERT VU#264212.
The early 2015 MaraDNS release will have this hardening code in it.
I do not feel this issue is critical enough to make an out-of-band new MaraDNS release, nor is it critical enough for me to muck around in the 1.4 codebase with. The attack requires the attacker to devote a lot of resources generating the “tarpit” DNS packets, and, since MaraDNS does not support Edns, amplification should be fairly minimal.
As an aside, this hardening code has finally made Deadwood too big to fit in 64kib, so I will no longer compile it with “-Os”, but have started compiling it will “-O3”; the -O3 binary is 150,671 bytes in size, which is still tiny, and it’s probably faster than the -Os binary.
The updated Deadwood is available here:
http://Comments are closedmaradns. samiam. org/ deadwood/ snap/