Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111117010045.GA18158@openwall.com>
Date: Thu, 17 Nov 2011 05:00:45 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2011-4313: BIND 9 Resolver crashes after logging an error in query.c

On Wed, Nov 16, 2011 at 11:43:25PM +0400, Solar Designer wrote:
> http://www.isc.org/software/bind/advisories/cve-2011-4313
> 
> "Versions affected:
> All currently supported versions of BIND, 9.4-ESV, 9.6-ESV, 9.7.x, 9.8.x"
> 
> Does anyone readily know if BIND 9.3.x is affected as well?

So I downloaded bind-9.4-ESV-R5-P1.tar.gz and bind-9.4-ESV-R5.tar.gz,
verified signatures, diff'ed these two trees, and then tried to apply
the resulting patch to 9.3.5 (just whatever version we happen to need a
patch for - obviously, only in case it is actually affected).  The
result of this is inconclusive.  On one hand, the code being patched is
mostly present in 9.3.5 as well, but on the other the checks that the
patch adds to lib/dns/rbtdb.c use the NEGATIVE() macro, which is not
present in 9.3.5.  While back-porting this macro definition is trivial,
and I've done just that, this source file in 9.3.5 lacks other likely
relevant pieces of code, including this one present in 9.4-ESV-R5's
lib/dns/rbtdb.c: addrdataset():

			newheader->attributes |= RDATASET_ATTR_NEGATIVE;

If 9.3.5 can't set this flag, then perhaps not checking for it was not a
problem.  Then the question becomes whether the fixes to
bin/named/query.c are required even when lib/dns/rbtdb.c did not have
the problem.  In other words, are these a security fix for a separate
attack vector (even if a similar one) or merely a hardening measure?
Or are the changes to lib/dns/rbtdb.c merely a hardening measure?  I am
not familiar with this code and with the specific attack(s), so I don't
know the answers.

I've attached the 9.4-ESV-R5 to 9.4-ESV-R5-P1 diffs, and a "patch"
against 9.3.5 - even though in the latter the changes to lib/dns/rbtdb.c
are almost certainly not needed, as I explained above.

Also, is BIND built without DNSSEC support affected?  The ISC advisory
does not mention DNSSEC and RRSIG, but bind-9.4-ESV-R5-P1/CHANGES
mentions RRSIG, which is a DNSSEC thing.  (Yes, we build BIND without
DNSSEC on Owl currently since DNSSEC proved to be more of a risk than a
solution so far - and it looks like we have yet another example here.
This is going to change, though, as DNSSEC gets deployed in more places.
So we might have to revert that temporary decision and re-include DNSSEC
support already in our next release.)

I am still looking for more conclusive info and more detail on this.

Alexander

View attachment "bind-9.4-ESV-R5-P1.diff" of type "text/plain" (3831 bytes)

View attachment "bind-9.3.5-up-CVE-2011-4313.diff" of type "text/plain" (2513 bytes)

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.