LWN.net Logo

Some stupid ideas

Some stupid ideas

Posted Aug 13, 2008 23:46 UTC (Wed) by njs (guest, #40338)
In reply to: Some stupid ideas by rvfh
Parent article: Details of the DNS flaw revealed

You don't even have to wait -- you know something funny is going on from the very first bogus
packet you receive (since the attacker has to send thousands of bogus packets before one of
them will chance to be valid).

That still doesn't tell you what to do, though.  Besides page the sysadmin, I mean, which
isn't going to be very effective on a consumer router.

I guess one of the pieces of information you can extract from the bogus packet is what cache
entry the attacker is trying to poison, and then treat that entry more carefully -- e.g., you
could put a flag on that entry, and when you receive an apparently valid value, if the flag is
set then you clear the flag but *don't* cache the value you received; this would mean that an
attacker had to spoof you on two transactions in a row without sending any bogus packets in
between in order to successfully poison your cache.  You can tune how many bogus packets are
required to set the flag and how many valid responses are required to clear the flag to
trade-off between safety and joe-job potential, but really if someone is flooding you with
thousands of UDP packets then running even dozens of extra queries is not going to be your
performance bottleneck.


(Log in to post comments)

Some stupid ideas

Posted Aug 14, 2008 10:08 UTC (Thu) by NAR (subscriber, #1313) [Link]

I think this is a good idea. RFC 1035 states that "TTL is a 32 bit signed integer that specifies the time interval that the resource record may be cached", so this actually would not break the DNS specification.

Some stupid ideas

Posted Aug 14, 2008 10:51 UTC (Thu) by rvfh (subscriber, #31018) [Link]

In this case, one could ask for each value (or only the ones under attack) twice:
- ask value, return to requester with short TTL (a few seconds)
- wait a bit
- ask value again, if matches use given TTL (or limit it to a few hours)

Anyway, it seems the solution is in the repetition, to decrease the probability of success of
the attack.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds