
A deep look at BIND9 CVE-2015-5477 - jgrahamc
https://blog.cloudflare.com/a-deep-look-at-cve-2015-5477-and-how-cloudflare-virtual-dns-customers-are-protected/
======
cft
I wonder if this can be used to automatically shut down the DNS servers
participating in a reflected DDoS recursion attack: those are unpatched.

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

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

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

------
dolfje
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](https://scan.patrolserver.com/bind/CVE-2015-5477)

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

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

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

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

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

