mailing list archives
Re: Thoughts about DNS...
From: tqbf () ENTERACT COM (Thomas H. Ptacek)
Date: Sun, 27 Apr 1997 04:19:40 -0500
Its more dependable than trying to depend on some type of cookie hidden in
areas that arent guaranteed to come back unmangled
Perhaps we're not in sync with each other. I get the impression that my
"cookie" idea (probably because I use the term "cookie" to describe it) is
being assumed to be something more complicated than it is.
All the "cookie" consists of is a totally standard DNS query. It could
just as easily be an A record query for SPLOITS.CERT.ORG as it could be a
type 212, class 13 query for DF97H37F74H4H3778FGH3F747.74TF784GF84GF4. The
point, of course, is simply that it's not trivial to guess, and we'll only
get a response back if the server we query is alive.
Under what circumstances would a 1 question nonrecursive query ever be
"mangled"? Is there a nameserver out there that destroys the question
section of DNS packets?
Well, if the tcp connection also fails, we can return failure and try
again later.. So each lookup request that the attacker generates will give
If the TCP connection fails, it will never work. There's a chance that it
will fail, because servers don't necessarilly *have* to allow TCP DNS
(firewall configurations, for instance, might make this impossible).
On the other hand, nothing should cause a simple UDP query to fail. It
also doesn't require connection setup (how will this affect latency?).
sysadmin noticing all of the logs spewing out.. Again, the best protection
would be cryptography
Yes, this is of course true, but it's probably not reasonable to expect
the entire Internet to switch to a cryptographically secure DNS protocol
That doesn't work. This is a blind attack; I can make the queries come
You can probably configure what addresses you'll accept recursive queries
from in the bind config also.. Ill check it out
That doesn't work. This is a blind attack. I can make the queries come
from wherever I want them to. Eliminating recursive queries is not, from
what I can see, a valid solution to this problem. Am I wrong?
TCP-ready BIND servers are probably 99% of the internet. However, if you
I don't set firewalls up to accept incoming TCP connections to port 53. At
the very least, every firewall I've configured is now broken.
find that cookies work more reliably, then that would be the superior
solution. It certainly has more room for strange failures though
You seem to think that there's alot of weirdness happening here. I don't
think there is. Can you come up with some specific things that can cause
weird failures? I'm not doing *anything* weird with DNS packets - I'm just
sending queries for information I don't care about.
The same with the cookies, except over a larger range of ID space. Also:
That larger range of DNS space is how many bits of random data, now?
If the DNS cookie solution works reliably, guessing cookies is no longer a
feasible attack, nor is brute-forcing cookie-space. The only attack
remaining is the race condition against the 16 bit ID.
However, I have to grant you that if a TCP connection is successful,
you've eliminated the problem entirely - you just finish the request over
TCP, and you know that you're getting reasonably authentic information
Unless, of course, I can predict the sequence numbers involved in setting
up the connection, or otherwise subvert the connection to fail or be
what do you do if a server doesnt return your cookies? Return a failure?
If a server doesn't return my cookies, it's dead. Try the next server.
Continue until SERVFAIL.
Well, with the method I am proposing, a DOS attack will only be possible
if port 53 is unavailable on the authoritative nameservers for the domain
How hard is that? SYN SYN SYN SYN SYN SYN SYN SYN *cough* *gag*
Again, we now have denial-of-service coupled with security; the attack
only needs to work once.
that is being blocked. So the problem no longer lies in your nameserver,
it is now a problem of the site being blocked for whatever reason, and
would have to be fixed on that end. What else can be done on our end?
Our security shouldn't rely on any site's servers working.
Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf () enteract com]
"If you're so special, why aren't you dead?"
Re: CPSN 4-970424: Possible buffer overflow in pop3d Andy Church (Apr 28)
- Re: Overflow in xlock, (continued)