A deep look at BIND9 CVE-2015-5477 | Hacker News Reader

A deep look at BIND9 CVE-2015-5477

blog.cloudflare.com

83 pointsjgrahamc12 comments

I wonder if this can be used to automatically shut down the DNS servers participating in a reflected DDoS recursion attack: those are unpatched.

With an attack like that, you know the inbound IPs targeting you are already vulnerable, so know what you can do? You can turn them back on themselves to attack the attack.

This approach is not recommended by legal professionals.

Attacking them back involves DDoS, I.e. time, infrastructure and legality issues. This stops an attack instantly.

Well, you can reflect their bad DNS back at them using their own methods. You can write less than 200 lines of code to destroy your attackers.

Morally right in an if-someone-tires-to-kill-you-kill-them-right-back way? Certainly legally wrong since most of the participants in these attacks are misconfigured "innocent" 3rd parties, not hostile entities themselves.

Amusingly in their 2012 talk at Defcon CloudFlare talked about using Unpatched Open DNS Resolvers to basically reflect back against themselves until they all crashed as a way of mitigating a DDoS.

The problem is the internet can't handle that much bandwidth at once. While every Open DNS Resolver would crash, so would the whole internet :P

You can check your server easily without doing the real attack. Because that would result into a denial of service. You just check the version of BIND in the linux terminal: dig @google.com version.bind chaos txt

If that is one of the following (or higher), you are save: 9.10.2-P3, 9.9.7-P2, 9.9.5-3ubuntu0.4, 9.8.1.P1-4ubuntu0.12, 9.9.5-4.3ubuntu0.3, 9.9.5-9ubuntu0.2, 9.9.4-18.el7_1.3, 9.8.2-0.37.rc1.el6_7.2, 9.3.6-25.P1.el5_11.3, 9.7.0-21.P2.el5_11.2, 9.8.4.P1-6+nmu2+deb7u2~bpo60+1, 9.7.3-1~squeeze16, 9.8.4.P1-6+nmu2+deb7u6, 9.9.5-9+deb8u2, 9.9.5-11

Ofcourse everything is easier if automated, so that is exactly what following page does: https://scan.patrolserver.com/bind/CVE-2015-5477

The one-line patch to dns_tkey_processquery() fixes the immediate problem, but until they clearly document the dangers inherent in dns_message_findname() they're just asking to have this happen again.

That's some odd code. What would be the point in requiring the pointer's target to be NULL?

n.b. it's a double-pointer. The /called/ code probably allocates a dns_name_t itself, updating the /callee's/ pointer. If the callee's pointer isn't NULL, there's a chance overwriting it will cause a memory leak (as the caller may no longer have a reference to whatever it was pointing to). The comment acknowledges that it's perhaps unnecessarily strict.

Hrm, it was a worthwhile check imho. Without the check, the memory leak you've indicated would have allowed the same packet to cause an out-of-memory DOS.

Working within the constraints of a lower level language where it's difficult (you could use a struct, often in a typedef, but then all callers would need to unpack/work with it...) to return arbitrary tuples of data.

Looks like something that should have been caught with a unit test that would test all possible error paths.

Reply on news.ycombinator.com