[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130114053719.GA12579@openwall.com>
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.
