| |||||||||||||
|
| |||||||||||||
Recursive servers, but not proxy servers, affected.Recursive servers, but not proxy servers, affected.Posted Jul 8, 2008 23:10 UTC (Tue) by nix (subscriber, #2304)In reply to: Recursive servers, but not proxy servers, affected. by endecotp Parent article: Dan Kaminsky Discovers Fundamental Issue In DNS: Massive Multivendor Patch Released (Securosis.com)
The GNU libc stub resolver is the resolver in libc which reads /etc/resolv.conf and satisfies requests from almost all actual programs for names (the commonest class of programs that don't use the libc resolver are those that need asynchronous name resolution). It's derived from BIND8 code (IIRC, it may even be late BIND4). This pretty much means that all Linux systems are vulnerable to cache pollution unless they are going via a non-vulnerable caching nameserver under control of someone trusted. However, since it's only a stub resolver and doesn't do recursive lookups, everyone has to use some caching nameserver anyway, simply for performance reasons... so this isn't so significant a problem. (adns, fairly widely used as a stub resolver when asynchronous name resolution is required, has the same flaw, if flaw it is.)
(Log in to post comments)
Recursive servers, but not proxy servers, affected. Posted Jul 9, 2008 12:44 UTC (Wed) by nix (subscriber, #2304) [Link] Its BIND 8-derived, and as far as I can tell it does source port randomization (at least the source ports it uses on my system, with a pristine glibc 2.7, are randomized, assuming a sufficiently recent kernel).
Recursive servers, but not proxy servers, affected. Posted Jul 10, 2008 12:19 UTC (Thu) by BenHutchings (subscriber, #37955) [Link] I suspect that the glibc stub resolver justs bind its socket to an unspecified port, which is fairly random after the system has been running for a while (whereas BIND typically starts shortly after the machine is booted). But an attacker can find out which source port you're using if you ever send a query to a DNS server they control. If I understand correctly, the source port needs to be randomised for each query (i.e. the resolver keeps re-binding to specified random ports).
Recursive servers, but not proxy servers, affected. Posted Jul 10, 2008 12:30 UTC (Thu) by nix (subscriber, #2304) [Link] Aha. It can't persist the socket but has to re-bind(). OK, glibc's not doing that. (Can you tell I've not done much UDP stuff? I love the Internet: I can let my ignorance and incompetence hang out for all to see!)
glibc Posted Jul 9, 2008 18:52 UTC (Wed) by ncm (subscriber, #165) [Link] As I recall, GNU libc doesn't cache DNS results, by default. It can be told to cache results, but they never expire, and the cache grows without bound. Perhaps it is the lack of expiration that makes it unfixable, and perhaps the default mode (and impractical optional mode) that makes it of little concern. My information might be out of date; has it changed since 1999?
glibc Posted Jul 9, 2008 20:54 UTC (Wed) by nix (subscriber, #2304) [Link] I can't see any sign that glibc's internal libresolv or nss-dns layer can be told to cache anything but DNS server addresses at all. (Of course nscd can cache DNS responses, and expire them.)
glibc Posted Aug 5, 2008 4:26 UTC (Tue) by rickmoen (subscriber, #6943) [Link] Nathan (ncm) might be thinking of the caching that transpires if you start the nscd (nameservice caching daemon). It's commonly used on systems with heavyweight lookup regimes (NIS, NIS+, LDAP) to prevent system performance from bogging down excessively, by locally caching lookup of hosts, users, groups, services, RPC ports, netgroups, etc. but has the drawback that it ignores TTL values on host lookups. (That's a sufficient reason to disable host caching in /etc/nscd.conf .) The BIND8-derived stub resolver in glibc isn't a huge security risk on most systems despite its haplessly failing to randomise UDP source ports, because the result doesn't get cached. (Thus, sending it poisoned data in an ADDITIONAL SECTION portion of a recursive DNS response doesn't do the attacker much good, because the poison gets metaphorically flushed immediately.) However, such a system with nscd caching hostnames would have a problem. (So, Don't Do That, Then.) Rick Moen rick@linuxmafia.com
glibc Posted Aug 5, 2008 8:38 UTC (Tue) by nix (subscriber, #2304) [Link] nscd in glibc 2.8 honours TTLs.
|
|
||||||||||||