The cat is out of the bag - DNS spoofing details | Hacker News Reader

The cat is out of the bag - DNS spoofing details

amd.co.at

55 pointsst3fan13 comments

Open articleView on HN

Here's a non-pastebin destroyed version: http://blogs.buanzo.com.ar/2008/07/matasano-kaminsky-dns-for...

Here's the CERT vulnerability listing, with a list of affected vendors:

http://www.kb.cert.org/vuls/id/800113

We use MaraDNS, and it was very comforting to see this on their blog:

http://maradns.blogspot.com/2008/07/maradns-is-immune-to-new...

Google Reader can be used as a pseudo-cache: http://www.google.com/reader/view/feed/http://www.matasano.c...

This is the best explanation of all the DNS stuff I've ever read.

tyme July 21st, 2008 9:45 pm Nate: as I understand it, the additional RR is the key. You can’t keep requesting the foo.com NS record and trying to poison with forged responses because it’ll be cached. You can keep requesting bogus_random.foo.com, because each different one will generate a new recursive query. Then mallory can reply with a foo.com NS record (or http://www.foo.com A record) as an additional RR.

</quote> http://www.matasano.com/log/1105/regarding-the-post-on-charg...

This is a good description of the attack.

I don't see why it should accept any address that isn't needed for the original query. Even if it does accept those additional addresses, surely they should be held in a separate area and only used for that particular query and nothing else?

If I'm understanding your question correctly, the Matasano post outlines why/how.

Last paragraph:

"It also contained Additional RRs pointing WWW.VICTIM.COM to 6.6.6.0. Those records are in-bailiwick: Bob is in fact interested in VICTIM.COM for this query."

Why would it accept a record for www.victim.com for a query against aaaaa.victim.com, when www.victim.com isn't needed for that particular query?

Surely the fix is to further restrict fix 2: "The RR set poisoning attack is fixed by bailiwick checking, which is a quirky way of saying that resolvers simply remember that if theyâ€™re asking where WWW.VICTIM.COM is, theyâ€™re not interested in caching a new address for WWW.GOOGLE.COM in the same transaction."

Change that to say they are only interested in addresses that help them resolve the current query, and they will only use those intermediate addresses for the current query, and not globally.

Okay, I misunderstood it. Yes, what you're suggesting (basically to only keep the glue for the current query and not to cache it, right?) would be a fix.

Buuuut you'd have to consider that legitimate glue usage includes A records for NS records.

My friend insists, 'please don't bring down the internet. I need it. It can't go down. I need to write my grant proposal.'

Real men use IPs only ;)

Actually real men use /etc/hosts :)

is it just me or is the scenario he describes fundamentally wrong. if we want to poison 'Bob's' nameserver, we have to get 'Alice' to send a request to the legitimite nameserver of victim.com, and then spoof the request to ALICE, not Bob. Its almost as if he's changed the meaning of Alice and Bob in the final scenario.

Reply on news.ycombinator.com