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: <20071102122343.GA2053@sentinelchicken.org>
Date: Fri, 2 Nov 2007 08:23:43 -0400
From: Tim <tim-security@...tinelchicken.org>
To: Shane Kerr <Shane_Kerr@....org>
Cc: bugtraq@...urityfocus.com
Subject: Re: Comments re ISC's announcement on bind9 security

Hello Shane,

Thanks for your response, it was informative.

> Yes, ISC has finally gotten around to randomizing the source ports, as of
> 9.5.0a2. It is controlled by the "use-queryport-pool" option in the server
> section of the BIND configuration file. It defaults to "yes".
> 
> You can control how big the pool is with the "queryport-pool-ports" option. It
> defaults to 8 (an extra 3 bits of entropy).
> 
> This set of ports is refreshed periodically, with a frequency controlled by the
> "queryport-pool-updateinterval" option. (Personally I think this option adds no
> little value from a security point of view, but it doesn't hurt.)

I see.  Well, I guess it is a step forward, though based on the somewhat
vague description of how it works[1], it probably doesn't add much security
as implemented.  Obviously 3 bits isn't much and you're reusing ports
for a rather long period of time.  Given that your default refresh is
15min, I'm willing to bet that doing a refresh every few seconds is
going to cause performance issues?

Other resolvers use cryptographically random IDs *and* source ports for
every query, which brings you up to around 30bits of entropy, depending
on the assumptions you make about allocated ports. This makes blind
attacks much, much more difficult than just 16bits.  This isn't a new
thing.  These ideas were implemented at least 6 years ago.  If the ISC
was really concerned about protecting the public from these attacks,
they've had ample time to do something about it.

Perhaps it's more politically convenient to leave blind attacks in place
in order to push other agenda?  It seems invariably those making the
all-or-nothing argument that 16 bits (in reality 30 bits if you get off
your ass and think about it) is not enough entropy no matter the
generator are all too often pushing DNSSEC in the very next sentence.
I'm not saying DNSSEC is good or bad, and it is designed to remedy more
than just blind attacks, but it's unethical to ignore a problem that can
be mitigated in the short term just so a new technology can be forced
down people's throats in the long term.


tim


PS- My do not mean to flame you personally Shane.  My frustration is
    directed at the ISC generally.


1. http://www.isc.org/sw/bind/arm95/Bv9ARM.ch06.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ