Date: Sat, 13 Mar 1999 08:38:28 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Jesse <j@lumiere.net> Cc: freebsd-security@freebsd.org Subject: Re: bind 8.1.2 cache poisoning Message-ID: <Pine.BSF.3.96.990313083310.588A-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.05.9903130520380.7303-100000@leaf.lumiere.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 13 Mar 1999, Jesse wrote: > I scanned my archives of freebsd-security and bugtraq and was surprised > not to find aynthing on the topic. Sorry if I'm missing something > obvious.. > > I run an IRC server that's part of a small network. Recently I noticed one > user with a very obviously fake hostname. The user started bragging to > various people about it. He said that he had inserted bogus entries into > the cache of the nameserver. > > So I checked around and found in the Jan 99 section of rootshell an > exploit which claims to insert entries into the caches of bind 8.1.2 > servers (which is what I run and as far as I can tell is the latest > version). If this is true, as it appears, I'm wondering why there's been > no discussion of this anywhere (or any fixes). Seems pretty serious if > anyone can screw with your DNS cache.. > > Hopefully there's some sort of configuration error on my part that allows > this to happen, but I think I have a pretty normal, secure setup. > > Any comments? I thought I'd check here first before writing the bind > maintainers. So my comment is this--I don't know much about this specific attack, although it sounds familiar, but because DNS does not use cryptography currently, you should expect it to be spoofable. :-) In the end, the DNS packets travel in cleartext, unprotected, across the network to your local nameserver. Anyone out there is pretty free to forge packets, stuff them into other nameservers, etc. This is not very sociable behavior, but DNS was not really designed to protect against this. As with TCP, the use of sequence numbers can help make this hard to do if you're not actually on a router the original request/response passes through, but that's not really a very effective protection; it makes the attack a little harder if the attacker is not on a common network route. When DNSsec is available, hopefully this kind of problem will be a little more tractable. It won't necessarily save us from programming errors, but at least the protocol will be protected :-). You may want to go read bugtraq, bind-workers, etc, and see if there is any serious mention of it there. If not, consider sending email to the bind bug reporting address. It may be there is something in a recent patch, or something that could be put in a patch. But again, in a protocol with no crypto support that uses the open network, there is only so much you can do. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990313083310.588A-100000>