Date: Mon, 14 Jan 2013 09:37:19 +0400 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: DoS vulnerability in the BIND resolver (and potentially others) Florian - On Sun, Jan 13, 2013 at 11:26:17AM +0100, Florian Weimer wrote: > Scott Brynen described a behavioral change in some of the UltraDNS > authorative name servers: > > <https://lists.dns-oarc.net/pipermail/dns-operations/2013-January/009501.html> I've exchanged some e-mails with UltraDNS Support last week and was told they'd escalate my question, but I still haven't received an answer to it (they kept giving other sorts of answers instead). I am trying to find out their rationale behind completely refusing these queries as opposed to setting TC, which would avoid the traffic amplification and thus remove the incentive for use of this query type in attacks. My guess is that they might be dealing with currently ongoing attacks, which would not pick up the incentive change right away. But I wanted to hear something like this (or not) from them explicitly, with numbers. [ It appears that you're for complete refusal, too. It's a rare occasion where I happen to disagree with you on some issue. ] > Mark Andrews of ISC confirmed that this triggers a denial of service > condition in the BIND recursive resolver: > > <https://lists.dns-oarc.net/pipermail/dns-operations/2013-January/009506.html> > > I think he is right, but this obviously has to be fixed in the > resolver. Can this be assigned a CVE? What would the correct behavior be, in your opinion? Not try other servers on REFUSED, but return it to the client right away? How is this a DoS on BIND's recursive resolver, any more so than e.g. deliberately having many nameservers for a certain hostname and keeping all of them down? Wouldn't BIND's recursive resolver have to try them all in that case anyway, even after a fix for behavior on REFUSED? I am not convinced this deserves a CVE - but this might change if you explain. [ As to "easily" patching qmail, people on the dns-operations thread don't appear to realize how many qmail installs came with Plesk (and thus are not exactly open source and are operated by people who couldn't patch the code anyway). Perhaps if the situation persists (especially if more DNS hosting providers follow suit) Parallels will release a Plesk update with patched qmail, but even then most installs won't be upgraded soon, if at all, such as because their owners' Plesk license keys have expired (and renewal cost is significant). Plesk and web-based admin panels in general are a security problem of its own, but that's another issue, albeit a related one. Ditto about non-free software in general. ] Thanks, Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.