[nsp-sec] BIND advisory

[Michael Sinatra]

On 11/25/09 2:08 AM, Florian Weimer wrote:
> * Michael Sinatra:
> 
>> It has just been released.  It only affects you if you are doing DNSSEC
>> validation on your resolvers and have caching resolvers forwarding to
>> your validating resolvers (which will tend to set the CD bit on queries).
> 
> Could you clarify if this bug allows bypassing the in-bailiwick checks
> for that data?  The ISC advisory is rather ambiguous.

Yes.  The bug causes out-of-bailiwick data in the additional section to 
be cached if the CD bit is set.  (The announcement says that the CD and 
DO bits both have to be set, but only the CD bit needs to be set.)  If 
the CD bit is set in a subsequent query for the data that was cached 
from the additional section, that data will be returned in the answer 
section.  (The CD bit has to be set both times.)

The CD bit is commonly (a bit more commonly than the advisory 
acknowledges) set when a caching resolver is forwarding to another 
caching resolver.  This makes sense per RFC 4035 (section 3.2.2) as it 
allows a forwarding resolver to maintain its own DNSSEC policy separate 
from the upstream resolver.  BIND does this if DNSSEC is disabled on the 
downstream forwarding nameserver.  One of our sysadmins had a Debian 
system running a build of 9.4.x that triggered the problem, although it 
was first noticed by our email system, which uses a mix of BIND and 
unbound.  (unbound sets both CD and DO.)

I should thank UC Berkeley's very clueful email administrators, Jim 
Blair and Paul Fisher, who first noticed something was wrong and 
prompted me to investigate (while I was on vacation of course).

> Looking at the patch, it seems that the bug only applies to secure
> delegations, so you're affected only if you've installed trust
> anchors, which limits the impact of this bug.

Yes.  You must have a trust anchor above the apex of the zone being 
(incorrectly) cached.  Of course, if you use DLV, then the trust anchor 
is effectively at the root, and all zones are potentially vulnerable. 
The zone giving out the bogus additional section does not need to be signed.

> Do you know if the infinite loop alluded to in the patch can be
> triggered in an unpatched BIND as well?

In all of the troubleshooting I did, I never experienced an infinite 
loop.  I'll look at the patch again, but I think that one may be rather 
hard to trigger.

> Oh, and if you find security vulnerabilities in ISC software, you
> should make sure that you notify a coordinator prior to disclosure.
> ISC does not do this, which means that most users lack a patch they
> can install when the vulnerability is disclosed.

Hmmm.  Ok.  We can discuss that further off-list.

michael