At Mon, 11 Aug 2008 19:44:41 -0400, "Gabriel Somlo" <[EMAIL PROTECTED]> wrote:
> > Did you actually confirm this behavior? As far as I understand the > > code (and I actually checked the behavior previously) BIND9 doesn't > > replace an authoritative RRset with a glue. Or in other words, it > > strictly follows the rule of RFC2181. > > I was just trying to locate the code that's actually responsible for > Dan Kaminsky's > vulnerability. As described by him, upon successful poisoning, the > attacker returns > a message that says "don't know the IP for abc123.foo.com, but check > with www.foo.com > at 5.6.7.8". The exploit relies on the fact that BIND will overwrite > its currently cached entry > for www.foo.com (1.2.3.4) with this new information (5.6.7.8). I was > trying to locate where > in the code this happens, and also to understand why it *has* to > happen that way (i.e., what > would break if I simply ignored the new info and kept my current data > in the cache)? If an implementation (wrongly) replaced an authoritative set with a glue (btw, there have actually been such (non-BIND9) implementations), Kaminsky's attack would be *even more effective*, but it's not the most essential part of this attack. Even if the implementation correctly prefers authoritative data over a glue (as BIND9 does), the attacker should simply waits for the time when the cached record expires (the attacker can detect the expiration time if they have the right to send queries to the caching server, or they can simply keep attacking). In this sense, the TTL actually matters a bit, but once the data expires the bad guy can repeat the attack as many times as necessary without worrying about TTL (until, of course, some other client asks the name under attack like 'www.foo.com'). --- JINMEI, Tatuya Internet Systems Consortium, Inc.
