HN Explorer

14 comments

[ 3.5 ms ] story [ 50.0 ms ] thread
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.
mjevans
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.
[deleted]
(comment deleted)
cautious_int
Looks like something that should have been caught with a unit test that would test all possible error paths.
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.

valarauca1
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

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.
[dead] dangtard
But but if we wrote this in rust or go, our farts would smell of roses! Steve klabnik said so!
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