[26010] in bugtraq
Re: Remote buffer overflow in resolver code of libc
daemon@ATHENA.MIT.EDU (Brett Glass)
Sat Jun 29 00:35:59 2002
Message-Id: <4.3.2.7.2.20020626174448.00e8b3a0@localhost>
Date: Wed, 26 Jun 2002 17:50:40 -0600
To: Mark Lastdrager <mark@pine.nl>, bugtraq@securityfocus.com
From: Brett Glass <brett@lariat.org>
Cc: vulnwatch@vulnwatch.org, vuln-dev@securityfocus.com,
editors@daemonnews.org
In-Reply-To: <20020626073716.GF25834@pine.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
The libc resolver bug (does glibc have the bug too, by the way?) has the
potential to affect not only the base operating sytem but everything
that's been statically linked with that library. Because the effort
involved in rebuilding EVERYTHING is so great, perhaps there's a way to
shield systems against this bug without rebuilding them.
What if one were to firewall direct DNS traffic to and from the outside
world, requiring all queries to go through a local DNS server (or a
"cache," as Dan Bernstein calls it)? The one server would be allowed
access to the rest of the world through the firewall, and could ensure
that no other machine gets a response that might trigger the bug.
On individual machines, one could direct all queries to localhost and set
up one's favorite name daemon (e.g. BIND or djbdns) to "sanitize"
incoming responses.
I am not familiar enough with the internals of the varions name daemons
to know if they already do this or can easily be modified to do so. Can
anyone out there on Bugtraq comment on this approach?
--Brett Glass
