bugtraq - Re: Comments re ISC's announcement on bind9 security

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071101205019.GG2631@sentinelchicken.org>
Date: Thu, 1 Nov 2007 16:50:20 -0400
From: Tim <tim-security@...tinelchicken.org>
To: Theo de Raadt <deraadt@....openbsd.org>
Cc: ntn@...workontap.com, bugtraq@...urityfocus.com
Subject: Re: Comments re ISC's announcement on bind9 security

> It _is_ a 16 bit ID space, and that is not fixable inside the strict
> DNS protocol, but that still leaves us room to do the best job with
> what we have, rather than do nothing at all.  Some people appear to be
> on the edge of arguing that we do nothing.

I have to agree with Theo on this.  It doesn't help a lot in theory, but
it helps quite a bit in practice.  Note that in spoofing responses one
does typically have timing issues involved which makes it tougher than
just guessing one of 65536 values alone.

On another note, why is it that everyone arguing the all-or-nothing case
likes to ignore the other very-usable-now mitigation of randomizing
source ports?  I don't use BIND and I don't care to check it's current
behavior, but has the ISC finally gotten around to randomizing the
source ports?  If not, why not?  The extra few bits of entropy can go a
long way, particularly if a good PRNG is used.

tim