Kaminsky's DNS Attack Disclosed, Then Pulled

An anonymous reader writes "Reverse engineering expert Halver Flake has recently mused on Dan Kaminsky's DNS vulnerability. Apparently his musings were close enough to the mark to cause one of the Matasano team, who apparently already knew of the attack, to publish the details on the Matasano blog in a post entitled 'Reliable DNS Forgery in 2008.' The blog post has since been pulled, but evidence of it exists on Google and elsewhere. It appears only a matter of time now before the full details leak." Reader Time out contributes a link to coverage on ZDNet as well.

Comments

The push for DNSSec

[QuantumG]

Kinda makes you wonder what they're getting out of it.

Re:The push for DNSSec

[dintech]

Fame? Notorioty? Unstoppable attractiveness to women?

Re:The push for DNSSec

[Anonymous Coward]

Secure DNS hopefully, so that we can put the DNS forging ISPs and DNS "services" behind us.

Re:The push for DNSSec

[gatekeep]

DNSSec is still the only ultimate patch for this. Source port randomization just makes it difficult to do given currently available processing and bandwidth capacity. Instead of 16 bits of entropy to crack (DNS Transaction ID) we now have rougly 32 (DNS Transaction ID + Source port).

Given enough bandwidth, we're still vulnerable to poisoning, but it's not feasible today.

DNSSec is more future proof. No matter how much bandwidth you have, guess a full certificate is orders of magnitude harder.

Re:The push for DNSSec

[snowgirl]

Fame? Notorioty? Unstoppable attractiveness to women?

Hey, you all are laughing now, but I tell you, there's a whole throng of us women just waiting for the right guy to secure our DNS!

Re:The push for DNSSec

[Anonymous Coward]

From Russia, with love!

Re:The push for DNSSec

[geekgirlandrea]

Whereas us lesbians can secure our own DNS just fine, but would still prefer to have some nice girl do it for us. :)

Re:The push for DNSSec

[Yeff]

Hottest. Slashdot Thread. Ever!

Re:The push for DNSSec

[Element119]

if only i were a female, i'd be a lesbian for sure.

Re:The push for DNSSec

[mrsbrisby]

Paul is an idiot and a douchebag. He's been lying to you for a long time to cover his own ass: BGP routes are filtered everywhere which means that not only do you have to break the port, and the sequence number, you also have to break the route filtering every AS is already doing.

Meanwhile, had BIND simply gone and removed the stupid ADDITIONAL-section processing like DJBDNS did, you wouldn't be having the described vulnerability.

Re:The push for DNSSec

[0xygen]

Not to state the obvious, but possibly a secure DNS system?

Although, it has been mentioned that there are a number of competing similar commercial solutions available from the big routing / switching manufacturers. However then you would expect them to want to delay DNSSec as much as possible.

Re:The push for DNSSec

[0xygen]

Not to be paranoid, but the argument of "no-one can do this" is often weak in the light of it being governments or intelligence agencies who are trying to mess with your internet access.

Is he scared of his government?

Or concerned about what his government may be doing to others in the world?

The problem is not necessarily on the "some attacker half way across the world on another AS", but may be much closer to home.

Re:The push for DNSSec

[Michael Hunt]

BGP routes are filtered when they're exchanged between eBGP routers. If you don't filter, you're an idiot. This I agree with.

You're not talking about BGP route filtering, though; you're talking about some kind of reverse path filtering (making sure that a route to the source address exists on the interface that you received the packet from). In practice, you almost never do this on BGP routers, as RPF makes some (somewhat naive) assumptions about the symmetry of Internetwork traffic.

Most people who have some kind of RPF deployed have it on a customer-facing device, as you generally only have one route per customer (and can make assertions about traffic NOT coming via that route, AND traffic COMING via that route.)

That said, not an awful lot of people even have RPF deployed. Certainly nowhere near 100%. And it only takes one (or a handful of machines) that can forge UDP source addresses for this to be an issue.

Re:The push for DNSSec

[neomunk]

Sorry for the threadjack (thank you for ensuring that 99% of the slashdot crowd is looking intently upon the thread), but here's soem relevant info that should be near the top.

As of the time of my post, the original text of the article (at least I -THINK- it's the original text) is available here

Slashdotters may resume the lesbian thread now, thank you for your time (hope I didn't kill anyones chubber).

Re:The push for DNSSec

[Anonymous Coward]

Too bad DNSSEC sucks and causes new problems, like listing all the records in your entire zone whether you like it or not through a linked list of NSEC records. Don't forget to have a cron job to sign your keys every 15 days (they expire every 30 days), and then have another cron job on a separate machine check your keys for expiration if the first cron job fails. If you forget to do this, DNSSEC validating cache servers will give an NXDOMAIN as if your site doesn't exist.

I'm trying to implement cryptography everywhere I possibly can, but DNSSEC is just a boondoggle. Sorry ISC, I'm avoiding it like the plague until a real workable solution emerges.

Re:The push for DNSSec

[Anonymous Coward]

It's not up to the manufacturers, it's up to the registries. In any case, the problem isn't manufacturers, it's governments/politicians.

Re:The push for DNSSec

[Anonymous Coward]

hope I didn't kill anyones chubber

On the contrary...

Re:The push for DNSSec

[afidel]

Are you saying there are STILL ISP's not doing egress filtering?!?!? That was known to be necessary back in the early-mid 90's. The fact that someone stupid enough to not do it today is allowed to peer is mind boggling.

Re:The push for DNSSec

[SecureThroughObscure]

bad ass

Re:The push for DNSSec

[Anonymous Coward]

Can I watch your hot lesbian friend secure your DNS connection ?

Re:The push for DNSSec

[mrsbrisby]

Actually, for multihomed sites it's even easier.

Getting BGP feeds from nearly every provider requires giving them your AS numbers (including those of all your downstreams and upstreams), and IP blocks- you already have the source routing information. They do this to prevent you from publishing routes for microsoft.com into some black hole someplace.

In fact, many ISPs do infact drop packets with an "invalid" source address- one that they couldn't have learned. All ISPs should do this, and immediately render most practical UDP attacks moot.

Re:The push for DNSSec

[mrsbrisby]

To be blunt, "the government" can crack your DNSSEC keys as well.

LAN security doesn't enter into it- if your cache is on the same machine, and you're using switched ethernet to the border, any remaining attack vectors "close to home" remain on the same level as transparent proxies and whatnot.

Where is your god then?

Re:The push for DNSSec

[Trogre]

Really dumb question, but why can't we patch BIND to do what DNSSec does?

Re:The push for DNSSec

[QuoteMstr]

DNSSEC does not require listing your whole zone: NSEC3

Stop spreading FUD.

Re:The push for DNSSec

[Michael Hunt]

It's a hard call in some cases. There's an argument that most (any?) multihomed customers should be able to send packets asymmetrically. That said, nobody with even half a brain should be running a NAS/LNS with single-homed customers WITHOUT RPF, although the (admittedly, in .au) number of people i've crossed paths with who are doing it wrong is staggering.

Conversely, if i'm peering with you and six other guys, and happen to be carrying traffic to your network (but not advertising a route back to some of MY peers, for e.g. traffic engineering reasons) across a given link, you have no business dropping that traffic.

RPF is a good idea, but it kind of breaks one of the more fundamental paradigms of the Internets.

Re:The push for DNSSec

[totally bogus dude]

BIND supports DNSSec; DNSSec is about cryptographically signing your DNS entries so resolvers know that the response they got was from the legitimate authoritative server for the domain.

This means that it's not something you can "just patch" - it actually requires people to do some work, which means it'll take a very long time to actually be widely deployed (by "people" I mean "every single person who administers one or more DNS zones"). You also have the usual problems with crypto, i.e. establishing a "web of trust" (it's all very well if records under google.com are signed, but how do you know they're signed by Google?).

Solvable problems, but inertia is a powerful force.

Re:The push for DNSSec

[Anonymous Coward]

I'm pretty sure the parent actually masturbated after posting.

Re:The push for DNSSec

[TheLink]

"also have the usual problems with crypto, i.e. establishing a "web of trust" (it's all very well if records under google.com are signed, but how do you know they're signed by Google?)."

Oh, I'm sure it'll require certs being signed by some CA.

Some CA that we can "trust" (to do the wrong thing). Go see what the CA companies really do. See who they are linked to, and who gets the $$$.

This DNSSec thing is such a great solution huh?

Re:The push for DNSSec

[Cramer]

Cisco has a "reachable by any" mode, but it's seen as an ugly hack. It's always better to do it on the customer interfaces anyway. You only need to filter "your own" traffic on the core routers -- that's often easier to manage and that class of router is better designed for that sort of traffic filter. (i.e. it only needs to check a rather small access list once per flow.)

Re:The push for DNSSec

[Cramer]

*ding* You win a cookie. That's exactly what we're saying. There are more ISPs that don't filter traffic than those that do. IP filtering is expensive business at ISP traffic rates. My little Cisco 1760 handles the 5-7Mbps that goes through it rather well. Multiply that by thousands, and that's what ISP's deal with. (Note: a full rate DS3 will swamp a 2851, and that's a pretty damned expensive bit of gear. but it's cheaper than a DS3 PCI(-X/e) card.)

Re:The push for DNSSec

[Cramer]

Multihomed customers are (or should be) handled carefully. They need to bring you their own assigned address space, and preferablly their own AS#. And then it's setup just like the ISP's own address space. (upstream ISPs and peers updated as necessary. blah. blah.)

However, more often than not, I'd get schmucks who wanted to have ISP#2 announce the /28 we assigned them -- that's a "Hell. No. If you do it anyway, we will sue you." (not to mention it won't work... anything smaller than /19 is not guaranteed to be globally routable; anything smaller than /24 is filtered almost everywhere.) Sometimes we were ISP#2 -- I laughed at those customers.

Re:The push for DNSSec

[ewanm89]

Federal/National governements can just change the countries root records anyway...

Re:The push for DNSSec

[macbayboy]

How about to get people to fix their insecure DNS!

Re:The push for DNSSec

[Kent Recal]

RPF is a good idea, but it kind of breaks one of the more fundamental paradigms of the Internets.

For the non-technies among us: On the internet nobody cares that you're a dog!

Re:The push for DNSSec

[0xygen]

That's what the Open Server Root Network is for, to prevent those "above us" from being able to apply politics to the DNS infrastructure, primarily the fear of ICANN being under the control of the US Government.

Re:The push for DNSSec

[0xygen]

Indeed, they can crack my key. However, if they want to divert an entire site's traffic for all users, it means they have a large number of keys to break in very little time. With the existing infrastructure, they can do it across the board without having to spend money on cracking every key. In the current situation, doing it to everyone is not a significantly larger problem that doing it to an individual.

Re:The push for DNSSec

[Anonymous Coward]

Threadjack? That's what I'm sayin!

Re:The push for DNSSec

[Anonymous Coward]

Not to be paranoid, but the argument of "no-one can do this" is often weak in the light of it being governments or intelligence agencies who are trying to mess with your internet access.

If your concern is a government agency, then this fix isn't going to help you anyways.

Adding a bit more hidden data an attacker will need to know isn't going to help you when the attacker can sniff your traffic and see that data.

Re:The push for DNSSec

[mrsbrisby]

No, it really doesn't. They simply ask your ISP to tunnel your IP into their site.

DNSSEC doesn't enter into it.

Re:The push for DNSSec

[makomk]

According to the Wikipedia article, that was developed in March 2008 (i.e. about 4 months ago), and some fairly major DNS servers don't support it yet. People have been trying to push DNSSEC for years, and yet this issue has only just been fixed in the spec.

Re:The push for DNSSec

[phorm]

In the case of some slashdotters, that would make them more manly than they currently are now :-)

Re:The push for DNSSec

[mrsbrisby]

Conversely, if i'm peering with you and six other guys, and happen to be carrying traffic to your network (but not advertising a route back to some of MY peers, for e.g. traffic engineering reasons) across a given link, you have no business dropping that traffic.

You can announce the route; just make the AS path realllly long so nobody will use it.

RPF is a good idea, but it kind of breaks one of the more fundamental paradigms of the Internets.

I disagree. It would solve this attack, and numerous others, and would in fact break very little.

Re:The push for DNSSec

[mrsbrisby]

I have a full-rate DS3 on a 600mhz Celeron, and six DS1 downstreams.

It isn't as expensive as you think.

Re:The push for DNSSec

[mrsbrisby]

The problem is that DNSSec doesn't do anything. It requires an infrastructure of trustworthy certificate authorities (like Verisign). It's akin to "SSL-encrypt everything and damn the costs".

Of course, it might be useful if DNSSec actually solved any issues that we're having, but it doesn't. DJBDNS is immune to this design flaw in BIND even though this design flaw has been brought up many times before. The real message you should be taking away from this is, and they expect us to trust them?

Re:The push for DNSSec

[neomunk]

LOL, I threadjacked the jackthread. Excellent.

Re:The push for DNSSec

[SCHecklerX]

Well, that's the whole problem right there. We don't want to secure it, we're trying to open it up!

Re:The push for DNSSec

[Znork]

I expect government agencies to have the ability to compel any participant in a PKI system to produce signed keys saying pretty much anything they want. Which is rather where PKI systems fail; as the third parties are not trustworthy they merely add a third party that can be compromised without notice, and which can now control the level of trust between the first two parties.

Re:The push for DNSSec

[Anonymous Coward]

Too bad DNSSEC sucks and causes new problems, like listing all the records in your entire zone whether you like it or not through a linked list of NSEC records.

So what? This is no different than allowing zone transfers, which, despite the recommendations of many security "experts" (who don't know beans about DNS) is in practice No Big Deal. If you're putting it out on the Internet it's public information anyway; don't try to "obfuscate" your way to security.

Re:The push for DNSSec

[Cramer]

I looked at those (back when they published prices), and yes, they are expensive. A 531-DE is $2500. We paid ~4k for the 2851 + NM1/T3. (amazing the discounts ISPs/integrators get.)

Re:The push for DNSSec

[deAtog]

The issue isn't so much as identifying who you are communicating with as much as it is ensuring that you're only communicating with one remote host. All the current DNS vulnerabilities exploit the fact that a third party can easily forge a response.

Encryption via public and private keys is the most effective way to currently ensure that you are actually communicating with a single remote host. The way it works is as follows:

If Bob wants to talk to Alice, Bob encrypts his message with Alice's public key. Alice decodes Bob's message with her private key and encrypts the response with Bob's public key. Bob can then decode Alice's response with his private key.

If Bob needs to ensure that he is indeed speaking to Alice, he can request Alice to encrypt all messages with her private key before encrypting them with his public key. Bob can then be assured the message came from Alice if he is able to decrypt it using his private key and Alice's public key.

Though Mallory could obtain Bob's and Alice's public keys, Mallory will be unable to decode any of the messages being sent since she does not know Bob's nor Alice's private keys. Mallory will therefore be unable decode the message or forge an appropriate response.

Re:The push for DNSSec

[snowgirl]

Sorry, but I'm wearing the HTTP panties "403 Forbidden" :) My ports are closed until you can find the right sized diamond to activate my modules...

God, I just gave up on that last word, and it still ended up being a sexual innuendo...

Re:The push for DNSSec

[Anonymous Coward]

I suppose I'm lucky. I'm a lesbian trapped in a man's body.

Re:The push for DNSSec

[mrsbrisby]

I paid 6K for a Gateway router, a 608 and a 532, and a couple 4pt D-Link ethernet boards. Direct from Imagestream.

I also got support at 3AM when Sprintlink's core BGP died a number of years ago, and when QWEST switched me from a Juniper to some Cisco with broken MLPPP implementation.

Cisco is a waste of money.

Re:The push for DNSSec

[totally bogus dude]

Fair enough, but how does one obtain the public key for each host you're talking to?

I don't know the details of how DNSSec is implemented, but my understanding is that the public keys are obtained through DNS. While it does mean an attacker probably only gets one shot at poisoning a resolver (because once it has the real public key it'll ignore anything the attacker sends it), if it does succeed then the resolver will ignore anything the real DNS server sends it.

That suggests you do need some kind of trust relationship so that when you receive a public key you can tell if it's the real deal or a fake one.

Also, yesterday I was reading about the problem of DNSSec making your entire zone walkable. This was basically because the NXDOMAIN responses had to be signed so you could trust them, but couldn't actually be signed because it's generally considered bad practice for a live DNS server to have the private key (the zones should be signed offline, then transferred to the DNS server). If this is the case, how does a DNS server decrypt messages encrypted with its public key?

My understanding is that they wouldn't; requests wouldn't be encrypted, but the responses are signed and that's how the resolver can determine whether the response is genuine or not.

Re:The push for DNSSec

[Anonymous Coward]

Alright guys. I am a techie and fairly linux-savvy, but I am not a CS major nor am I a networking expert. That's a lot of jargon that flew over me in this discussion so far.
So somebody help me. How can I protect myself from this DNS-level flaw? Please post an advice.

Re:The push for DNSSec

[0xygen]

You probably want to check how asymmetric crypto actually works.

The private keys are not visible on the wire, so once you receive the signed response, you can veryify that the answer is coming from where you hope it is. To modify the response, the attacker requires access to the private keys.

The point of DNSSEC is to prevent Bob's site masquerading as Alice's trusted site without your knowledge.

SSL (and so by extension SSH and HTTPS) attempt to solve this problem by verifying the identity of the other site, which is why we should always use it for trusted transactions.

Re:The push for DNSSec

[0xygen]

Yes, clearly diverting an entire connection worth of traffic *for each target user* seems a lot more painful than screwing with as a few ISP DNS servers to redirect all users of the target site to the evil site.

The way I see it, part of the point of the vulnerability is it is possible to poison it WITHOUT the co-operation of the point you are attacking, so in the case of dodgy surveillance, there is no legal papertrail.

Re:The push for DNSSec

[shentino]

I agree, and would like to further add that the government's policy on treating encryption and security as munitions to be regulated or banned is complete BULLSHIT.

Pirates, scammers, crackers, and hackers, simply by outnumbering the government a bazillion to one, so to speak, are in a position to do loads MORE damage than the government can. This, combined with the fact that their intentions ARE malicious (we really DO want to hurt you) as opposed to misguided (we want to HELP you, we just suck at it), means that the criminal element poses a far greater danger to commerce and computing in general than does the government.

The government's presence, like it or not, prevents anarchy, and if you take away the police, you let the crooks run amok, and pretty soon you have a dictatorship police state headed by the mafia, since they'll be the ones on top of the black market etc and thus in a position to fill the power vaccuum that would be created without the government's presence. (Just look at Iraq. Soon as we topple the regime, radicals barge in.)

So let us defend ourselves against cybercrooks with encryption and security, the same way laymen defend themselves against robbers and burglars with guns and militias.

I think that the "right to bear arms" should be extended to firewalls, encryption, and so on.

If the government wants access to our networks for a GOOD reason, nothing is going to stop them from getting a warrant LIKE THEY SHOULD. If it's an emergency enough to make them panic and say "LET US IN NOW!!!" then they should already have enough to say "BECAUSE OF ", at least, to a judge. Either way, probable cause should be cake for the feds if there really is a need for access.

Bottom line, networks have ample enough cause to defend themselves against the REAL bad guys through encryption and passwording and to make it very much not worth weakening the defenses to make it easier for government snoops. The only legitimate access by the government is either through the front door, or in cases where there is probable cause and the government should be getting a warrant anyway.

Re:The push for DNSSec

[deAtog]

I'm not familiar with the specifics of how DNSSec works, but public keys are usually exchanged during the initial stages of the conversation. For example, Bob might start the conversation by telling Alice his public key and ask that she send him her's. At this point, Alice has two options. She could just tell Bob her public key, or she could encrypt her public key with Bob's public key. The second option is slightly more secure, since anyone listening to the conversation would only have heard Bob's public key.

The only issue with public/private keys is that it is susceptible to a man in the middle attack. As soon as Bob announces his public key, anyone pretending to be Alice could reply with their public key. This is what key signing is supposed to solve.

Re:The push for DNSSec

[kayditty]

That said, not an awful lot of people even have RPF deployed. Certainly nowhere near 100%.

It feels like it's getting there to the blackhats. Ten years ago, my friends and I used to do "smurf" attacks indiscriminately from just about everywhere. It takes more effort than it's worth to find a network that will let you spoof properly anymore, so most people just resort to making lazy DDoS nets -- formerly relegated to high-bandwidth UNIX servers on .edus and the like, but now it's just as well to make use of every little Celeron desktop with a cable modem, since it's so easy to get high numbers of bots.

It looks like Steve Gibson was a bigger idiot than anyone could've imagined. But XP did make it easier to facilitate the growth of a DoS botnet.

Re:The push for DNSSec

[I)ruid]

a/s/l? (:

Re:The push for DNSSec

[Anonymous Coward]

Brazilian government would surely like that:
http://www.nardol.org/2008/7/18/the-new-brazilian-internet-surveillance

No details?

[TobyMurray]

What sort of tease posts this story without the details contained in the pulled Matasano post?

Re:No details?

[flosofl]

I still have it in my RSS reader. I sent the others in my security group the link referenced in the feed, but it ended up with a 404 page. I thought it was a blip on their server, but now I see they retracted the post. It's a bit late for that, as I'm sure I'm not the only one who subscribes to their blog.

Just another example of how you can't erase knowledge once it's been disseminated.

BTW, the method of attack really is quite clever. And pretty trivial.

Re:No details?

[neomunk]

You still have the text? CopyNPaste FTW!

For the mod points too.. I'm sure some kind hearted (or ruthlessly evil, given the content) soul will mod you informative for your troubles. I would, had I not precluded my chance to do so by posting this request.

Re:No details?

[NickFitz]

... it ended up with a 404 page. I thought it was a blip on their server, but now I see they retracted the post.

They fail. If they've removed it with no intention of making it available again it should be 410 Gone, not 404 Not Found. Am I the only person who reads the HTTP spec? It's not exactly hard to understand...

Re:No details?

[Alsee]

Actually you have the answer within your own post. As you said "If they've removed it with no intention of making it available again". According to the spec "If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead." It is quite possible that the page was only taken down temporarily, with the intent to restore it on the official disclosure date. So use of code 410 which would be in violation of the spec, and 404 the proper reply code.

Tag: geek humor

-

Re:No details?

[petermgreen]

They fail. If they've removed it with no intention of making it available again it should be 410 Gone [w3.org], not 404 Not Found [w3.org].
Indeed but it is only a SHOULD not a MUST and keeping the information as to whether the condition is temporary or permanent (indeed that may not even have been decided at the point the content is removed) would be a PITA so noone does it.

Re:No details?

[ccguy]

10.4.11 410 Gone [...] If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead.

For a split second I thought this was conclusive evidence that there were people in slashdot who completely read and understand specs.

Glad to see it's a false alarm, business as usual.

Re:No details?

[flosofl]

It is *all* over the place now. Just Google it. You'll find it pretty quickly.

Re:No details?

[neomunk]

Yeah, I found it right after making this post, and threw a link up myself, having hijacked some good-ole' lesbianism to make it more visible.

Here's the whole post

[Anonymous Coward]

http://demosthen.es/post/43048623/matasano-briefly-had-a-post-up-about-the-dns-flaw

Re:Here's the whole post

[Anonymous Coward]

Even google scrubbed it from the cache .. maybe there are enough people out there unpatched that this is still a security risk.

Re:Here's the whole post

[Tony Hoyle]

Doesn't sound that complex to fix - just make the checking for additional records a lot more stringent so you can't poison WWW.DOMAIN.COM within a reply to AAAAA.DOMAIN.COM

Re:Here's the whole post

[davester666]

From reading the f'ing article, I now know that I should never try to resolve WWW.VICTIM.COM.

Re:Here's the whole post

[Anonymous Coward]

Ok, here's the gist: It's difficult to spoof a response for the right domain name, because of the random query IDs. You need too many requests and caching servers don't usually ask for the same name very often. But it's easy to get a caching server to ask for many different names in a subdomain, so do that and send your fake answers. One of them is going to get accepted sooner or later. Include spoofed glue for the real subdomain (www...) in your answers. Because the glue is for the same domain, it is accepted. Tadaa, poisoned DNS.

Re:Here's the whole post

[Anonymous Coward]

After reading the entire article, my point of view is that assholes that go to delis and order a ham sandwich deserve their strychnine.

I am hopeful that Mallory will succeed in poisoning Bob.

(Whatever happened to Mallory anyway, she was sort of cute, though I would have figured it was Alex who would do the poisoning in that family.)

Re:Here's the whole post

[snowgirl]

Doesn't sound that complex to fix - just make the checking for additional records a lot more stringent so you can't poison WWW.DOMAIN.COM within a reply to AAAAA.DOMAIN.COM

Won't work... the problem is that you're setting NS1.VICTIM.COM while searching for WWW.VICTIM.COM

If you implement the fix you fix the bug, but you just threw out the baby with the bathwater... now everyone needs to double their DNS requests to find out what the address for the NS server is.

Re:Here's the whole post

[mysidia]

Ok.. if your DNS cache is willing to accept that glue despite the fact a better entry should already be cached, sure.

I wonder if based on that concept a bad guy could try to do poison lookups for millions of TLDs (most of which don't exist). And once successful include spoofed glue for "."....

Re:Here's the whole post

[Tony Hoyle]

You don't need the address for the NS server as you're getting a result already. If you didn't ask for the information then it shouldn't be in the reply - if it is just discard the entire packet as bogus and keep listening for the real one.

Re:Here's the whole post

[0xygen]

Yes, I agree - reading the article the resolver should only allow responses which are necessary glue for the provided response through and drop all other RRs.

Re:Here's the whole post

[spyder-implee]

Reliable DNS Forgery in 2008: Kaminsky's Discovery from Matasano Chargen by ecopeland 0. The cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan Kaminsky will announce at Black Hat. 1. Pretend for the moment that you know only the basic function of DNS -- that it translates WWW.VICTIM.COM into 1.2.3.4. The code that does this is called a resolver. Each time the resolver contacts the DNS to translate names to addresses, it creates a packet called a query. The exchange of packets is called a transaction. Since the number of packets flying about on the internet requires scientific notation to express, you can imagine there has to be some way of not mixing them up. Bob goes to to a deli, to get a sandwich. Bob walks up to the counter, takes a pointy ticket from a round red dispenser. The ticket has a number on it. This will be Bob's unique identifier for his sandwich acquisition transaction. Note that the number will probably be used twice -- once when he is called to the counter to place his order and again when he's called back to get his sandwich. If you're wondering, Bob likes ham on rye with no onions. If you've got this, you have the concept of transaction IDs, which are numbers assigned to keep different transactions in order. Conveniently, the first sixteen bits of a DNS packet is just such a unique identifier. It's called a query id (QID). And with the efficiency of the deli, the QID is used for multiple transactions. 2. Until very recently, there were two basic classes of DNS vulnerabilities. One of them involves mucking about with the QID in DNS packets and the other requires you to know the Deep Magic. First, QIDs. Bob's a resolver and Alice is a content DNS server. Bob asks Alice for the address of WWW.VICTIM.COM. The answer is 1.2.3.4. Mallory would like the answer to be 6.6.6.0. It is a (now not) secret shame of mine that for a great deal of my career, creating and sending packets was, to me, Deep Magic. Then it became part of my job, and I learned that it is surprisingly trivial. So put aside the idea that forging IP packets is the hard part of poisoning DNS. If I'm Mallory and I'm attacking Bob, how can he distinguish my packets from Alice's? Because I can't see the QID in his request, and the QID in my response won't match. The QID is the only thing protecting the DNS from Mallory (me). QID attacks began in the olden days, when BIND simply incremented the QID with every query response. If you can remember 1995, here's a workable DNS attack. Think fast: 9372 + 1. Did you get 9372, or even miss and get 9373? You win, Alice loses. Mallory sends a constant stream of DNS responses for WWW.VICTIM.COM. All are quietly discarded --- until Mallory gets Bob to query for WWW.VICTIM.COM. If Mallory's response gets to your computer before the legitimate response arrives from your ISP's name server, you will be redirected where Mallory tells you you're going. Obvious fix: you want the QID be randomly generated. Now Alice and Mallory are in a race. Alice sees Bob's request and knows the QID. Mallory has to guess it. The first one to land a packet with the correct QID wins. Randomized QIDs give Alice a big advantage in this race. But there's a bunch more problems here: * If you convince Bob to ask Alice the same question 1000 times all at once, and Bob uses a different QID for each packet, you made the race 1000 times easier for Mallory to win. * If Bob uses a crappy random number generator, Mallory can get Bob to ask for names she controls, like WWW.EVIL.COM, and watch how the QIDs bounce around; eventually, she'll break the RNG and be able to predict its outputs. * 16 bits just isn't big enough to provide real security at the traffic rates we deal with in 2008. Your computer's resolver is probably a stub. Which means it won't really save the response. You don't want it to. The stub asks a real DNS server, probably run by your ISP. That server doesn't know everything. It can't, and shouldn't, because the whole idea of DNS is to compensate for the organic and shifting nature of internet nami

Re:Here's the whole post

[Anonymous Coward]

Yep. this is something I was talking about for a long time (but noone listens). No DNS server should EVER accept any answers to anything it has not explicitly asked for. The whole idea of these "apropo" glue records etc is ridiculous and ripe for exploit just like that.

Re:Here's the whole post

[Anonymous Coward]

Some glue records are necessary. When a .com nameserver tells you that ns1.domain.com is authoritative for domain.com, you can't look up that name unless you already know the answer. Additionally the circularity can span multiple domains: ns1.domain-a.com is authoritative for domain-b.com, ns1.domain-b.com is authoritative for domain-a.com. If the resolver does not accept glue for both ns1.domain-a.com in requests for domain-b.com and ns1.domain-b.com in requests for domain-a.com, then it can't resolve either of those nameserver addresses and consequently none of the names in domain-a.com and domain-b.com.

Please explain how you propose to fix this.

Re:Here's the whole post

[mysidia]

An answer may be to use the glue to perform any lookup that can use it as part of that query, but never allow the glue itself to create a cached DNS entry; i.e. to have a life outside that lookup.

Except perhaps caching would be ok, if the cached result can be re-used _only_ when repeating the very same lookup that yielded the glue, the populated additional section.

This approach segments the returned additional section from the rest of the zone (helps constrain the poison to the one subdomain)

Re:Here's the whole post

[timotten]

Whatever happened to Mallory anyway, she was sort of cute...

Mallory is a guy. Don't ask me why.

Personally, I'm waiting for the Third Edition of Applied Cryptography. Rumor is that Mallory will be replaced by Amy Acker.

Re:Here's the whole post

[DarthJohn]

I got a 404. Shit! My DNS has been poisoned!

Re:Here's the whole post

[stevied]

So ns1 is listed as the server for the subdomain as well, and glue supplied? Why doesn't bailiwick checking apply here as well - only ns1.aaaa.victim.com etc. being allowed?

I'm with Tony Hoyle - I can't (at the moment) see a reason why a query to an (apparently) authoritative server for a subdomain should reasonably be allowed to contain glue for the parent.

Re:Here's the whole post

[AftanGustur]

Here is why it works (I think):

Malory wants to poison the server ns.polya.com

Malory sends NS requests for ulam00001.com, ulam00002.com ... to ns.polya.com.

Malory then sends a forged answer from the .com server, saying that the NS for www.ulam00002.com is ns.google.com *AND* puts a glue record saying that ns.google.com is 66.6.6.6

Because the glue records corresponds with the answer record, (same domain) the targetted nameserver will cache or replace it's curent record of ns.google.com to be 66.6.6.6

Hmmm, can't be that simple, can it ?

Re:Here's the whole post

[**loki969**]

It is still shown on pastebin ;)

here ya go:
http://amd.co.at/dns.htm

Re:Here's the whole post

[snowgirl]

You don't need the address for the NS server as you're getting a result already. If you didn't ask for the information then it shouldn't be in the reply - if it is just discard the entire packet as bogus and keep listening for the real one.

Why? Because of recursion... Rather than asking up the line to the root DNS machines, peers can talk to themselves to speed up getting answers.

Someone who knows more about how DNS works could explain better, but it's nice to get an answer back about who is authoritatively saying that's the DNS address. ("Ping, hey, ns1.google.com, what address does www.google.com have? Hm... doesn't agree with mine, looks like I can fix that information, thanks!")

Re:Here's the whole post

[snowgirl]

You don't bailiwick every subdomain, it wouldn't work.

When asking about www.victim.com, you get an answer for aaa.victim.com, telling the difference between aaa.victim.com and ns1.victim.com would be impossible. The bailiwick can really only at best check all but the last subdomain, and even then you might get an answer about the authoritative NS server for ns1.victim.com, while asking for computer1.corp.victim.com or whatever...

Re:Here's the whole post

[stevied]

OK, so diffing against the matasano post:

"Poisoning CXOPQ.VICTIM.COM is not super valuable to Mallory. But Mallory has another trick up her sleeve. Because her response didnâ(TM)t just say CXOPQ.VICTIM.COM was 6.6.6.0. It also contained Additional RRs pointing WWW.VICTIM.COM to 6.6.6.0."

This is, then, not quite right? Rather Mallory's response would not list an A record for CXOPQ.VICTIM.COM, but instead another delegation, plus glue? There would be no reason to process glue if an authoritative A record response was returned ..

Is the fundamental underlying issue merely that it would break too many existing configs if caching resolvers were stricter? I hope Dan Kaminsky's eventual disclosure goes into a bit more detail on this. I'd also quite like to here what DJB has to say.

Re:Here's the whole post

[snowgirl]

OK, so diffing against the matasano post:

"Poisoning CXOPQ.VICTIM.COM is not super valuable to Mallory. But Mallory has another trick up her sleeve. Because her response didnâ(TM)t just say CXOPQ.VICTIM.COM was 6.6.6.0. It also contained Additional RRs pointing WWW.VICTIM.COM to 6.6.6.0."

This is, then, not quite right? Rather Mallory's response would not list an A record for CXOPQ.VICTIM.COM, but instead another delegation, plus glue? There would be no reason to process glue if an authoritative A record response was returned ..

Is the fundamental underlying issue merely that it would break too many existing configs if caching resolvers were stricter? I hope Dan Kaminsky's eventual disclosure goes into a bit more detail on this. I'd also quite like to here what DJB has to say.

Of course Mallory's response listed an A record for CXOPQ.VICTIM.COM ... and the authority for that record is listed as whatever. In addition to that is the glue that says "Hey, btw, WWW.VICTIM.COM is XYZ." Typically the glue is used to indicate the DNS authority of the information, however that DNS authority can really be anything... WWW.VICTIM.COM for all it matters, they really are free to name their name servers whatever they want.

The A record returned wouldn't be authoritative, it'd be the same kind of answer that the DNS cache would receive from its parent DNS, or what the end-user's computer would receive from its DNS cache. If you went and asked the authority for confirmation for that address, then there's no reason for the DNS cache.

There are a number of solutions, more accurately, the explanation is what the PROBLEM is, not what the SOLUTION was. That's what I'm looking forward to.

Re:Here's the whole post

[stevied]

(BTW, feel free to drop this conversation if you're fed up with dealing with the hard of thinking and - by this time of the evening - slightly inebriated.)

Of course Mallory's response listed an A record for CXOPQ.VICTIM.COM ... and the authority for that record is listed as whatever. In addition to that is the glue that says "Hey, btw, WWW.VICTIM.COM is XYZ." Typically the glue is used to indicate the DNS authority of the information, however that DNS authority can really be anything... WWW.VICTIM.COM for all it matters, they really are free to name their name servers whatever they want.

At this point, we should already be querying (what we think is) an authoritative server. If we're being returned an A record, and not an NS record, why would we process any glue? I thought Paul Vixie fixed this 13 years ago:

http://www.usenix.org/publications/library/proceedings/security95/full_papers/vixie.txt (see section 5.3, "Irrelevant Answers")

The A record returned wouldn't be authoritative, it'd be the same kind of answer that the DNS cache would receive from its parent DNS, or what the end-user's computer would receive from its DNS cache.

But at this point, we should be expecting an authoritative answer for CXOPQ.VICTIM.COM, or a referral with glue, but not a non NS record with glue, surely? Mallory's racing with the authoritative server for the domain we're trying to query..

If you went and asked the authority for confirmation for that address, then there's no reason for the DNS cache.

We're not talking about attacks on stub resolvers .. are we? (You can't poison the cache on a machine that doesn't have one.) The standard situation is that a stub resolver (e.g. Win XP machine) asks an ISP's caching resolver for an address; assuming the answer isn't already cached, the caching resolver figures out the appropriate authoritative server for that zone, and queries it. In the scenario that I think we're discussing, based on ecopeland's post, the attacker races with the authoritative server to get an answer to the caching resolver, and so (somehow) screw over all future clients of that resolver until the TTL expires.

Incidentally, assuming my understanding is close, even if section 5.3 of the Vixie paper hasn't been implemented sufficiently rigorously to prevent this attack (and obviously it hasn't, or there would be no panic), section 7.2 ("What we would like to do .. Hierarchical cache") should nail it. Now, this would be invasive, and so time consuming to test, but it should be penciled in as work to be done after the immediate band-aid has been applied. After all, this is 2008, we all grok Extreme Programming, surely with sufficient testing (unit and otherwise) this could be implemented. Let's face it, sufficiently widespread deployment of DNSSEC is about as likely to happen as IPv6 (sadly)..

Re:Here's the whole post

[stevied]

(Incidentally, I'm perilously close to actually installing BIND locally and poking it with a stick to see what all the fuss is about. I haven't gotten my hands that dirty in some time )

Re:Here's the whole post

[Martin Blank]

As I understand it, the attack is that simple, with the added caveat that the query ID has to match. By my calculations, a 1Mbps uplink can attempt around 1000 attacks per second (two UDP packets, one for the request and one for the spoof). Picking a query ID of, say, 3526 for the spoofed response sent, there's a 1/65535 chance of that matching the query ID. Odds are that it would take under a minute of that to successfully poison the server.

The server should be using randomized source ports, but many OSes do not properly randomize their use of ephemeral ports, and instead go sequentially. Watching for the source port used here (by querying against one's own DNS server) allows the source port to be guessed during the attack, reducing the range of ports to be attempted. Some DNS servers use port 53 as source and destination, which is even worse, and was recommended against long ago.

I'm not completely sure of what the patches changed. It's mentioned that source port randomization was enabled by Microsoft, and that at least some Unix vendors have disabled "query-source port" lines in their named.conf files. We should have some solid details no later than Kaminsky's talk at Blackhat.

FTA: Please...

[cez]

Perhaps someone whose income depends on phishing, and who is at the same time bright enough to build a reasonably complicated rootkit. This person is smart, and has a clear financial incentive to figure this out. I'd argue that it would take him N/4 days.

Give an evil genius some credit, 2 hours tops and half that time's spent reading /., most of the other half on other evil online things; like pr0n and goatse.

Isn't it okay to post by now anyways?

[perlchild]

I mean they coordinated this massive "patch" that's supposed to fix it. Now that it's fixed, it's not a secret anymore, or it this one of those cia secrecy where the reputation of those involved is at stake?

Re:Isn't it okay to post by now anyways?

[mad_psych0]

The recent availability of the patch is hardly reason to believe that everyone's already deployed it, which is I'm sure why there's still so much secrecy surrounding this.

Re:Isn't it okay to post by now anyways?

[cez]

I've heard of certain problems with at least IIS 6's DNS patch breaking certain servers [yeah yeah citations :]... just curious anyone with links to a "certified" fix?

Re:Isn't it okay to post by now anyways?

[Vancorps]

How would patching a DNS server break a web server? My guess is that someone was blaming the patch for a problem that they created themselves.

"Certified" fixes for MS products come from Windows Update or in certain extreme circumstances you have to request the file such as the case with the Exchange 2003 issue with calendar updates to Exchange 2007 systems. The dates get mangled so the server is unable to read further updates. Just an example from my world.

It is quite rare these days unless you're doing something supremely funky that a patch will break your stuff. Doesn't mean you shouldn't test of course.

Re:Isn't it okay to post by now anyways?

[jd]

As long as it remains secret, many shops will hold off patching their DNS server, assuming the problem to have been blown out of proportion.

Re:Isn't it okay to post by now anyways?

[Anonymous Coward]

Microsoft DNS is a house of cards.

Re:Isn't it okay to post by now anyways?

[cez]

Well I guess I don't know the credibility of what I came across in researching a different matter, but there was this description on experts-exchange.com (nope dont have the resolutions)here. I guess that's why I'm asking... any real world success / horror storries? Our issue turned out to be a newly rebuilt box after a failed hard drive with a mis-configured hosts file (that had had the patch applied, but was not the culprit).

Re:Isn't it okay to post by now anyways?

[Vancorps]

All of my servers are up-to-date with no issue which includes Windows Server 2003 R2, Windows Server 2008, SUSE Enterprise Linux, Oracle Enterprise Linux, CentOS, Debian, OS X and Ubuntu.

Of course just because it all snaps into place in my environment doesn't necessarily mean it will in yours. For instance, I don't do anything with HOSTS files as the situation has not called for it except on my workstation which is largely because I don't like ads.

There are a certain number of installs where Windows update will break, it's not a specific patch problem but an issue with the catalog stored on the computer. When the catalog is wiped Windowsupdate reapplies the failed update and away you go. I've had this happen on 1 in 10 Windows Server installs.

I've been deeply worried

[smittyoneeach]

...about these Monsanto DNA attacks for some time...

Google Reader FTW!

[Anonymous Coward]

i have matasano's blog in my google reader feed and the whole post is still available... very interesting article but i think it's better for Dan to fully disclose it than the matasano team

A: Because it breaks the flow of a message

[DNS-and-BIND]

Q: Why is starting a post in the Subject: line annoying?

Re:A: Because it breaks the flow of a message

[smittyoneeach]

Fair enough.
Possibly if they defaulted the top-level responses, starting the thought in the subject line would be less tempting.

Re:A: Because it breaks the flow of a message

[Koiu Lpoi]

Frankly, we should just do away with the subject line entirely. They generally just get filled with "Re:Re:Re:Re:Unoriginal First comment" anyways. It serves no purpose in a system like slashdot's, and causes things like the above.

Re:A: Because it breaks the flow of a message

[Anonymous Coward]

Q: Why is starting a post in the Subject: line annoying?

It's the only way to get such small, witty post modded up really.

Re:A: Because it breaks the flow of a message

[Anonymous Coward]

Because then there wouldn't be a nice header for your comment

Doxpara.com also updated.

[gatekeep]

Doxpara.com, the blog of Dan Kaminsky who first discovered the vulnerability, has also been updated.

In case of Slashdotting, here's the full update;

Patch. Today. Now. Yes, stay late. Yes, forward to OpenDNS if you have to. (Theyâ(TM)re ready for your traffic.) Thank you to the many of you who already have.

Re:Doxpara.com also updated.

[spankymm]

do NOT blindly forward to OpenDNS

They do not return NXDOMAIN for domains which don't exist.

Dan, not all of the internet is a web-browser.

Re:Doxpara.com also updated.

[Anonymous Coward]

I'm actually pretty certain that doxpara was updated as a response to the fact that Matasano leaked the full disclosure by accident. So for anyone who thought they had a couple more weeks to dilly dally or fight with their managers about whether or not they should be patching their name servers, guess what? Chances are your week just got pretty long.

For what it's worth, I patched immediately. All other BS aside, when the major vendors release updates at the same time and do absolutely no complaining about it, that's a pretty good indicator that the problem is significant

I got this much

[bluefoxlucid]

I got this much and am working on extracting more but hitting a roadblock.

Matasano Chargen  Blog Archive  Reliable DNS Forgery in 2008: Kaminskyâ(TM)s Discovery. Well the cat is finally out of the bag. I suspected this was how the

the cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan ... One of them involves mucking about with the QID in DNS packets and
and the other requires you to know the Deep Magic. First, QIDs
Bobâ(TM)s a resolver and Alice is a content DNS server. Bob asks Alice for the address of WWW.VICTIM.COM. The answer is 1.2.3.4.
Mallory would like the answer to be 6.6.6.0. It is a (now not) secret shame of mine
that for a great deal of my career, creating and sending packets was, to me, Deep Magic. Then it became part of my
job, and I learned that it is surprisingly trivial. So put aside the idea that forging IP packets is the hard part
of poisoning DNS. If Iâ(TM)m Mallory and Iâ(TM)m attacking Bob, how can he distinguish my packets
from Aliceâ(TM)s? Because I canâ(TM)t see the QID in his request, and the QID in my response
wonâ(TM)t match. The QID is the only thing protecting the DNS from
Mallory (me). QID attacks began in the olden days, when BIND simply incremented the QID
with every query response. If you can remember 1995,
hereâ(TM)s a workable DNS attack. Think fast: 9372 + 1. Did you get 9372, or even miss and get 9373?
You win, Alice loses. Mallory sends a constant stream of DNS responses for WWW.VICTIM.COM.
All are quietly discarded â"- until Mallory gets Bob to query for
WWW.VICTIM.COM. If Malloryâ(TM)s response gets to your computer before the
legitimate response arrives from your ISPâ(TM)s name server, you will be redirected where
where Mallory tells you youâ(TM)re going

Re:I got this much

[bluefoxlucid]

Found this while google screwing. Someone got it!

http://pastebin.ca/1078776

1.
Reliable DNS Forgery in 2008: Kaminskyâ(TM)s Discovery
2.
from Matasano Chargen by ecopeland
3.
0.
4.

5.
The cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan Kaminsky will announce at Black Hat.
6.
1.
7.

8.
Pretend for the moment that you know only the basic function of DNS â" that it translates WWW.VICTIM.COM into 1.2.3.4. The code that does this is called a resolver. Each time the resolver contacts the DNS to translate names to addresses, it creates a packet called a query. The exchange of packets is called a transaction. Since the number of packets flying about on the internet requires scientific notation to express, you can imagine there has to be some way of not mixing them up.
9.

10.
Bob goes to to a deli, to get a sandwich. Bob walks up to the counter, takes a pointy ticket from a round red dispenser. The ticket has a number on it. This will be Bobâ(TM)s unique identifier for his sandwich acquisition transaction. Note that the number will probably be used twice â" once when he is called to the counter to place his order and again when heâ(TM)s called back to get his sandwich. If youâ(TM)re wondering, Bob likes ham on rye with no onions.
11.

12.
If youâ(TM)ve got this, you have the concept of transaction IDs, which are numbers assigned to keep different transactions in order. Conveniently, the first sixteen bits of a DNS packet is just such a unique identifier. Itâ(TM)s called a query id (QID). And with the efficiency of the deli, the QID is used for multiple transactions.
13.
2.
14.

15.
Until very recently, there were two basic classes of DNS vulnerabilities. One of them involves mucking about with the QID in DNS packets and the other requires you to know the Deep Magic.
16.

17.
First, QIDs.
18.

19.
Bobâ(TM)s a resolver and Alice is a content DNS server. Bob asks Alice for the address of WWW.VICTIM.COM. The answer is 1.2.3.4. Mallory would like the answer to be 6.6.6.0.
20.

21.
It is a (now not) secret shame of mine that for a great deal of my career, creating and sending packets was, to me, Deep Magic. Then it became part of my job, and I learned that it is surprisingly trivial. So put aside the idea that forging IP packets is the hard part of poisoning DNS. If Iâ(TM)m Mallory and Iâ(TM)m attacking Bob, how can he distinguish my packets from Aliceâ(TM)s? Because I canâ(TM)t see the QID in his request, and the QID in my response wonâ(TM)t match. The QID is the only thing protecting the DNS from Mallory (me).
22.

23.
QID attacks began in the olden days, when BIND simply incremented the QID with every query response. If you can remember 1995, hereâ(TM)s a workable DNS attack. Think fast: 9372 + 1. Did you get 9372, or even miss and get 9373? You win, Alice loses. M

Re:I got this much

[snowgirl]

*GASP!*

It's like on the intartoobs nothing is ever gone once published.

It's true people, and well... be careful with what you post. INFORMATION SHOULD BE FREE (rather than anthropomorphised.)

Re:I got this much

[bluefoxlucid]

Yeah, it's there somewhere. Google's cache had the newer version, but their database had the full story. A few people had the full text in their RSS readers too. They dropped the ball.

Also, a girl? On Slashdot? Have we broken 20% yet? The nominal on IRC seems to be 3 boys for every girl, which is just about perfect for a lot of girls....

Re:I got this much

[Chris Burkhardt]

INFORMATION SHOULD BE FREE (rather than anthropomorphised.)

You're right. I asked my information his opinion on the matter, and he clearly said that he should be free, not so much that he wants to be free.

Re:I got this much

[Dramacrat]

http://beezari.livejournal.com/141796.html Enjoy.

Re:I got this much

[Anonymous Coward]

Reliable DNS Forgery in 2008: Kaminskyâ(TM)s Discovery
from Matasano Chargen by ecopeland

0.
The cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan Kaminsky will announce at Black Hat.

1.
Pretend for the moment that you know only the basic function of DNS â" that it translates WWW.VICTIM.COM into 1.2.3.4. The code that does this is called a resolver. Each time the resolver contacts the DNS to translate names to addresses, it creates a packet called a query. The exchange of packets is called a transaction. Since the number of packets flying about on the internet requires scientific notation to express, you can imagine there has to be some way of not mixing them up.

Bob goes to to a deli, to get a sandwich. Bob walks up to the counter, takes a pointy ticket from a round red dispenser. The ticket has a number on it. This will be Bobâ(TM)s unique identifier for his sandwich acquisition transaction. Note that the number will probably be used twice â" once when he is called to the counter to place his order and again when heâ(TM)s called back to get his sandwich. If youâ(TM)re wondering, Bob likes ham on rye with no onions.

If youâ(TM)ve got this, you have the concept of transaction IDs, which are numbers assigned to keep different transactions in order. Conveniently, the first sixteen bits of a DNS packet is just such a unique identifier. Itâ(TM)s called a query id (QID). And with the efficiency of the deli, the QID is used for multiple transactions.

2.
Until very recently, there were two basic classes of DNS vulnerabilities. One of them involves mucking about with the QID in DNS packets and the other requires you to know the Deep Magic.

First, QIDs.

Bobâ(TM)s a resolver and Alice is a content DNS server. Bob asks Alice for the address of WWW.VICTIM.COM. The answer is 1.2.3.4. Mallory would like the answer to be 6.6.6.0.

It is a (now not) secret shame of mine that for a great deal of my career, creating and sending packets was, to me, Deep Magic. Then it became part of my job, and I learned that it is surprisingly trivial. So put aside the idea that forging IP packets is the hard part of poisoning DNS. If Iâ(TM)m Mallory and Iâ(TM)m attacking Bob, how can he distinguish my packets from Aliceâ(TM)s? Because I canâ(TM)t see the QID in his request, and the QID in my response wonâ(TM)t match. The QID is the only thing protecting the DNS from Mallory (me).

QID attacks began in the olden days, when BIND simply incremented the QID with every query response. If you can remember 1995, hereâ(TM)s a workable DNS attack. Think fast: 9372 + 1. Did you get 9372, or even miss and get 9373? You win, Alice loses. Mallory sends a constant stream of DNS responses for WWW.VICTIM.COM. All are quietly discarded â"- until Mallory gets Bob to query for WWW.VICTIM.COM. If Malloryâ(TM)s response gets to your computer before the legitimate response arrives from your ISPâ(TM)s name server, you will be redirected where Mallory tells you youâ(TM)re going.

Obvious fix: you want the QID be randomly generated. Now Alice and Mallory are in a race. Alice sees Bobâ(TM)s request and knows the QID. Mallory has to guess it. The first one to land a packet with the correct QID wins. Randomized QIDs give Alice a big advantage in this race.
But thereâ(TM)s a bunch more problems here:

*If you convince Bob to ask Alice the same question 1000 times all at once, and Bob uses a different QID for each packet, you made the race 1000 times easier for Mallory to win.

*If Bob uses a crappy random number generator, Mallory can get Bob to ask for names she controls, like WWW.EVIL.COM, and watch how the QIDs bounce around; eventually, sheâ(TM)ll break the RNG and be able to predict its outputs.

*16 bits just isnâ(TM)t big enough to provide real security at the traffic rates we deal with in 2008. Your computerâ(TM)s resolver is probably a stub. Which mean

Re:I got this much

[Anonymous Coward]

Also, a girl? On Slashdot?

Ugh - what is it with you geeks having no fucking class whatsoever?
Are you so afraid of girls that you need to try to alienate them?

Re:I got this much

[bluefoxlucid]

Hmm? Nah, I like girls.

Re:I got this much

[snowgirl]

Also, a girl? On Slashdot? Have we broken 20% yet? The nominal on IRC seems to be 3 boys for every girl, which is just about perfect for a lot of girls....

*gasp* OMGWTFBBQ?!?!?!

Re:I got this much

[snowgirl]

INFORMATION SHOULD BE FREE (rather than anthropomorphised.)

You're right. I asked my information his opinion on the matter, and he clearly said that he should be free, not so much that he wants to be free.

You know, I asked my data for their opinion, and they said the very same thing.

Re:I got this much

[bluefoxlucid]

Mmm, barbecue...

*is immediately distracted*

Re:I got this much

[kv9]

Also, a girl? On Slashdot?

I think we need more cooking threads then. or at least the omgponies pink theme brought back.

Re:I got this much

[Chris Burkhardt]

INFORMATION SHOULD BE FREE (rather than anthropomorphised.)

You're right. I asked my information his opinion on the matter, and he clearly said that he should be free, not so much that he wants to be free.

You know, I asked my data for their opinion, and they said the very same thing.

As for my datum, it disagrees. An argumentative little datum it is.

Re:I got this much

[snowgirl]

*flashes her boobs, and laughs at the ease of distracting men*

Re:I got this much

[snowgirl]

INFORMATION SHOULD BE FREE (rather than anthropomorphised.)

You're right. I asked my information his opinion on the matter, and he clearly said that he should be free, not so much that he wants to be free.

You know, I asked my data for their opinion, and they said the very same thing.

As for my datum, it disagrees. An argumentative little datum it is.

That's quite the unusual phenomenon... perhaps I should alert a medium...

Re:I got this much

[bluefoxlucid]

Hold on, let me finish these ribs. A man can juggle a lot of stuff at once but boobs need to have their own special distraction time.

Re:I got this much

[snowgirl]

*blink blink*

Homer: "Can't talk... eating..."

Re:I got this much

[bluefoxlucid]

Hahaha...

I thought chicks were supposed to be into Family Guy, not The Simpsons!

Re:I got this much

[snowgirl]

Well, there was a time when only The Simpson's were on, and Family Guy wasn't on... note, the quote is definitely from an older episode. (From a Krusty Burger on an Oil Rig, I recall)

Family Guy? Pfff... we'll just see you get through my impenetrable fort, and then I might discuss with you the cinematic value of the second chicken battle vs the first one.

Re:I got this much

[bluefoxlucid]

Yeah that's true, I used to love watching the Simpsons. Then Family Guy, Futurama...

Then TV became too boring to entertain me, and I started going to video game cons, and building guitar amplifiers. (Building guitar amps == "WARNING: HIGH VOLTAGES, DANGEROUS, NO USER SERVICEABLE PARTS INSIDE, YOU WILL DIE" hmm ok I'll just build my own *700V on the plates instead of 300V* ... I've got to be pining for a darwin award or something)

Re:I got this much

[snowgirl]

Yeah that's true, I used to love watching the Simpsons. Then Family Guy, Futurama...

Then TV became too boring to entertain me, and I started going to video game cons, and building guitar amplifiers. (Building guitar amps == "WARNING: HIGH VOLTAGES, DANGEROUS, NO USER SERVICEABLE PARTS INSIDE, YOU WILL DIE" hmm ok I'll just build my own *700V on the plates instead of 300V* ... I've got to be pining for a darwin award or something)

0.0 yeah... I think so. Does yours go to 11?

Re:I got this much

[bluefoxlucid]

ELEVEN?!

http://www.musiciansfriend.com/product/DiMarzio-Bell-Replacement-Knob-111?sku=424664

I used to be able to get knobs that went to 12...

Everything about this flaw is being kept quiet

[Anonymous Coward]

There were other issues regarding this patch that still have never seen the light of day, not even a note in passing.

In the hours after the initial vendor announcement and the following 2 days, the .com.au name servers were returning useless and corrupt answers.

I don't have any output from the issue any more, but I can make it up :P
eg. dig example.com.au NS
; ANSWER
(none)
; ADDITIONAL
(correct A records for the missing NS)

This meant that your normal resolver could not figure out who the MX was for com.au domains unless it still had the information about the NS servers was still in cache. Since I had just updated and restarted all the local named, this cache was gone. It did not show in non-production testing as I didn't check a specific country name server, just google/yahoo.

Did anyone run into similar issues or even know of any news or blog reports on this? It seems to have been completely swept under the carpet.

You can play with the search query

[mysidia]

Use Google search snippets to expose little details of the document...

I'm guessing some persistent folks will eventually be able to piece the bits together.

i.e. see how much you can piece together from the summary with the result shown by google. Adjust your search by including unique words towards the end of the snippet in one search to try to get the text that follows.

1

2

21 Jul 2008 ... One of them involves mucking about with the QID in DNS packets and the ... The QID is the only thing protecting the DNS from Mallory (me). ...

21 Jul 2008 ... If Mallory wins, the next 10000 or so people that ask that cache where WWW.VICTIM.COM is go to 6.6.6.0. 3. Then thereâ(TM)s that other set of ... 21 Jul 2008 ... Then thereâ(TM)s that other set of DNS vulnerabilities. ... Then letâ(TM)s set up an evil server with it, and register it as EVIL.COM. ...

21 Jul 2008 ... EVIL.COM, and watch how the QIDs bounce around; eventually, sheâ(TM)ll break the .... EVIL.COM and slipping strychnine into his ham sandwich, ...

21 Jul 2008 ... This will be Bobâ(TM)s unique identifier for his sandwich acquisition transaction. Note that the number will probably be used twice â" once when ...

21 Jul 2008 ... Which sends back a response with an unexpected (evil) Additional RR. ... Weâ(TM)ll come back to it. Alice has an advantage in the race, ...

21 Jul 2008 ... Alice has an advantage in the race, and so she likely beats Mallory. NXDOMAIN for AAAAA.VICTIM.COM. Aliceâ(TM)s advantage is not insurmountable. ...

21 Jul 2008 ... Aliceâ(TM)s advantage is not insurmountable. Mallory repeats with AAAAB.VICTIM.COM. Then AAAAC.VICTIM.COM. And so on. ..

21 Jul 2008 ... Frequently, that server has to go ask another, and so on. .... And so on. Sometime, perhaps around CXOPQ.VICTIM.COM, Mallory wins! ...

21 Jul 2008 ... If Mallory wins, the next 10000 or so people that ask that cache where WWW .... COM, Mallory wins! Bob believes CXOPQ.VICTIM.COM is 6.6.6.0! ...

21 Jul 2008 ... Poisoning CXOPQ.VICTIM.COM is not super valuable to Mallory. ... Because her response didnâ(TM)t just say CXOPQ.VICTIM.COM was 6.6.6.0. ...

21 Jul 2008 ... COM was: 6.6.6.0. Every resolver that points to that name server will now ... COM to 6.6.6.0. Those records are in-bailiwick: Bob is in fact ...

Re:You can play with the search query

[bluefoxlucid]

Yep, that's how I got my copy. Then I found a pastebin in the middle of that junk that had the full text :)

Actually

[krkhan]

Well, as soon as he had posted that thing he got a Cease & Desist letter from MPAA for disclosing the intellectual property of Wachowski Brothers for The Matrix: Rebuttal. The movie was supposed to answer all the questions pertaining to the first movie and this attack was the secret way that Zion crafts used to hack into the Core. Of course, the Core refused to get its DNS servers patched because they didn't need anyone's help.

Ridiculous armwaving...

[actionbastard]

and running around the room screaming that the sky is falling.
An article over at the Register, states that this 'vulnerability' was discovered three years ago by Ian Green and published in a paper he wrote for the SANS Institute. While Kaminsky does deserve some credit for his organizational skills in getting people to act on this, that's about as far as his role goes. Since this has been known about for three years and we haven't seen anything 'in the wild' -until now that the media bandwagon is careening downhill on fire- just goes to show how hard this is to exploit.

Re:Ridiculous armwaving...

[supersat]

This isn't even close to the same attack. Newer DNS server have randomized query IDs, so spoofing DNS packets isn't nearly as trivial as it used to be. This attack appears to combine the birthday paradox attack strategy (sending lots of queries and replies so the probability of a spoofed QID matching is much higher) with adding resource records for the actual name you want to poison (under the same domain).

Re:Ridiculous armwaving...

[mysidia]

The responsible thing at this point would be for the vulnerability to be published. By now the bad guys surely already have the details and are in the process of selling exploit code to each other.

While the pro-security community is being left in the dark.

He may have considered new modes of attacks that had not yet been concerns.

For example... phishing wasn't such an issue back in the earlier 1990s when the original weakness was noted.

A DNS hijacker attempts to poison a particular domain on a DNS cache. That's the ordinary attack model a DNS server admin would be concerned about, right?

What if instead, the attacker doesn't care what domain they poison? Instead, they aim to attack major ISPs' DNS cache, or authoritative DNS servers' cache.

Instead of trying to poison one particular domain, they go down a HUGE dictionary of popular domain names, TLDs, etc.

And if their odds of each poison being successful are (1/2^16) based on being able to predict the source port?

They have a good chance of eventual success, by brute force, especially if they can reduce the search space for transaction id, or re-use a legitimate transaction id in an unexpected way.

The attacker doesn't care that his spoofed packets will be wrong or won't get there first for most domains.

Poisoning _just one_ popular domain with a bogus NS record may be a serious attack.

Once one poison is successful, if the future dns transaction ids/source ports are sequential, or even just pseudorandom, an attacker can possibly know that they have succeeded (By testing the success of their poison).

Knowing that they succeeded gives them the state of the RNG; they might also get that querying a domain whose authoritative DNS server is complicit to the attack (and will provide the attacker with the DNS request packet for analysis)

Re:Ridiculous armwaving...

[mrsbrisby]

While the pro-security community is being left in the dark.

The pro-security community has always been safe; DJBDNS and derivatives are immune to this attack and always have been.

Re:Ridiculous armwaving...

[mysidia]

Except that DJBDNS doesn't support DNSSEC. Which is not pro-security.

And when setting up an authoritative DNS server, it doesn't even properly support SRV records.

In reality there is DNS server software other than DJBDNS, BIND, et al. that have to be secured.

There are other caching DNS servers also. The advisories don't show whether they are considered vulnerable or not.

Re:Ridiculous armwaving...

[Anonymous Coward]

Of course he stole it, he is jewish. Thats what they do best.

Re:Ridiculous armwaving...

[Ice Station Zebra]

dnssec is a joke. It still doesn't fix the issue.
djbdns does support srv records http://www.anders.com/projects/sysadmin/djbdnsRecordBuilder/#SRV

Yes, there is other dns software other than bind. But djbdns is small, secure and easy to setup.

Re:Ridiculous armwaving...

[QuoteMstr]

DNSSEC a joke? Hardly. Care to elaborate on your alternate and better proposal?

Re:Ridiculous armwaving...

[mrsbrisby]

Yes, DNSSEC is a joke; it doesn't protect against anything happening in reality, and it requires a significant infrastructure that will simply never arrive. Paul is telling everyone to wait for that magic moment where everyone will be able to turn off their "insecure DNS" and replace it with "secure DNS"- it'll just never happen.

Meanwhile, had Paul actually listened to security professionals, Kaminsky's attack would never have happened. And yet, you think he his so above reproach that you practically consider the rejection of DNSSEC some kind of blaspheme.

Re:Ridiculous armwaving...

[mrsbrisby]

Just because it has "security" in the name, doesn't make it secure, Alice.

The patches make it clear that ADDITIONAL-section processing is to blame- just as it has been numerous times over the last twenty or so years. DJBDNS doesn't do ADDITIONAL-section processing and so it immune. BIND tries to do a lot of hand-waving to continue doing ADDITIONAL-section processing even though it's clearly a bad idea- in order to protect egos.

So the guy who rejects advise from the security community on src port randomization and ADDITIONAL-section handling; the guy who has had countless vulnerabilities, and the very same guy who has lied about BIND8 and BIND9's complete rewrites, that's the guy you're taking at his word regarding the security of DNSSEC?

By the way, DJBDNS supports all RR types- including those that haven't been invented yet, simply because it has an extensible data format.

Re:Ridiculous armwaving...

[mysidia]

Just because it won't reach critical mass for a time doesn't mean it's inferior.

It will be a long time for the magic moment where everyone will be able to turn off their old IPv4 and replace it with IPv6.

If DNSSEC is such ajoke, then how do you explain it being the standard? Or do you propose that the IETF is a joke also?

If you think DNSSEC is so poor, then what's your alternative that provides the same level of zone security?

Re:Ridiculous armwaving...

[TheLink]

DNSSEC is just a way for a CA to make lots of money.

They're already doing it for TLS/SSL/https certs.

Re:Ridiculous armwaving...

[mrsbrisby]

Just because it won't reach critical mass for a time doesn't mean it's inferior.

You're building a straw man mysidia: DNSSEC doesn't do what it claims to do, and doesn't do what people want out of a Secure DNS system.

If DNSSEC is such ajoke, then how do you explain it being the standard? Or do you propose that the IETF is a joke also?

There's a "standard" for IP over Carrier Pigeon. Anyone can submit a paper to the IETF standardization process, and if you get right once, IETF members tend to try to fast-track papers that you submit in the future.

However, the IETF doesn't make you do stuff. They aren't always right, and thy are very often wrong. Example: IQUERY is part of the standard, but no DNS servers support it because it's stupid.

If you think DNSSEC is so poor, then what's your alternative that provides the same level of zone security?

You're confused mysidia: The onus isn't on me to provide and design a perpetual motion machine just because I called Paul's perpetual motion machine broken and stupid.

Re:Ridiculous armwaving...

[Anonymous Coward]

DJBDNS is 'not' vulnerable because it randomizes source ports. The attack doesn't need additional records, as an authority section containing an NS record for an attacker controlled nameserver is what it takes.

DJBDNS also does not simply discard additional sections. That would break DNS.

Re:Ridiculous armwaving...

[mrsbrisby]

The attack doesn't need additional records, as an authority section containing an NS record for an attacker controlled nameserver is what it takes.

No, the cache has to trust this information.

DJBDNS also does not simply discard additional sections.

Not simply, no. It ignores them outright.

That would break DNS.

Clearly it does not.

Re:Ridiculous armwaving...

[Anonymous Coward]

If all you have is a referral, where the names of the nameservers are in the domain you're trying to query, then you must accept the contents of the Additional Section. There's no choice in the matter. It's a chicken-and-egg situation: you can't resolve the names to IP addresses without following the delegation hierarchy and you can't follow the delegation hierarchy without IP addresses to use.

So, your broad statement that djbdns ignores Additional Sections "outright" is flat wrong; there are scenarios where using the contents of the Additional Section is mandatory as per the protocol standards.

Re:Ridiculous armwaving...

[mrsbrisby]

Slashdot ate my url.

http://cr.yp.to/djbdns/dnscache.html

You're right though, my statement was overly broad.

Long story short

[losttoy]

This did occur to me earlier but seemed too simple.

Pick a few hundred ISP name servers. Craft packets with the the source address as that of your victim's name server's IP address and start sending them to the ISP name servers on your list.

Sooner or later, due to the non-randomized tracking number used by DNS requests, your false DNS replies will be accepted by one ISP nameserver. Because you set the TTL for the DNS record to be very high, the record will live in the ISP name server's cache for VERY long. Now all the ISP's customers will come to an IP address of your choosing when they type www.victim.com.

The internet is now 0wned.

What I was thinking is spraying the end users with spoofed DNS responses. Sooner or later, some would use your response to resolve the name but obviously poisoning an ISP name server is more profitable.

If this really is *the* attack then it was lame of the *researchers* to try and hide it. I am sure 1000s would've guessed it by now. The exploit is really simple with dozens of packet crafters out there

Here is hoping that the real vulnerability is a lot harder to exploit.

Re:Long story short

[losttoy]

With proper SSL certificates, savvy users might be able to avoid going to spoofed sites. Browsers like Firefox 3 will alert you of bad certs and all that.

But think of email delivery to wrong MX records .

Re:Long story short

[Anonymous Coward]

That is not it. What you describe would have worked a decade ago, but not today.

Re:Long story short

[skis]

Spraying end users with spoofed responses would not work because end users workstations do not talk to the authoritative nameserver directly. Additional Resource Records are only accepted if they are for the same second-level domain that you are asking about.

I have the entire article

[Rudd-O]

I have the entirety of the text of the article, since it's on my feed reader. You do not need to piece it together. Just ask me for it.

The futility of recalling the article should be a very good example of the stupidity in this "don't speculate about the DNS vuln" moronic exercise that is doing the rounds these weeks.

That's it

[krkhan]

I've had enough. From now on, /. isn't /. for me. It's 216.34.181.45. I'm updating all my bookmarks. Wait, why is it redirecting? I have a bad feeling about this. Itsatrick.

What about simple DSL SoHo routers with DNS?

[Anonymous Coward]

Do they also require a patch? They act as DNS for the local clients.

Who is ecopeland?

[Ancorehraq sis]

Did Matasano blog get broken into? "ecopeland" never posted there before

The significance of the attack...

[Rudd-O]

...is not just that you can race legit DNS servers for legit queries, is that you can request recursive resolution for bullshit DNS servers, while submitting fake answers WITH malicious informational records that let you poison second-level domains. So by requesting xxjk3j.google.com while submitting your own coolly crafted answer, you can make the victim DNS use YOUR DNS as authoritative for the future google.com replies.

THAT is the significance of the attack. THAT is what matasano pulled.

Re:The significance of the attack...

[Rudd-O]

Posted it on: http://rudd-o.com/archives/2008/07/21/the-dns-fiasco/

Re:The significance of the attack...

[mxs]

How nice of you to comment on your own website, not in the comment section where we might also read it unhassled.

May your DNS be poisoned.

Re:The significance of the attack...

[stevied]

Isn't the answer then simply better checking in the recursing resolvers?

If, as a caching resolver, I ask an (apparently) authoritative server for google.com for an A record for xxjk3.google.com, what am I doing processing any returned glue records?

I can think of other tricks, some simple, some more complicated, that might work, but I still don't feel that the whole story's out of the bag here yet -- not that I have a huge problem with that.

Re:The significance of the attack...

[Anonymous Coward]

Oh shit, that is why all those bogus pages have been popping into google. I never thought about it, but it's perfect, googlebot hits you, you hit google bot, and craft some love for it :-)

I thought this wasn't the X attack from Y..

[dnsfool]

If this is the real deal, there's some bogosity here. This is certainly not a new attack or flaw in the dns protocol, any more than run of the mill dns cache poisoning is. Spoofing responses from the root servers (to hijack a TLD) is difficult; their TTLs are long, there are many of them (more unpredictability), and most DNS servers service so many requests that it's unlikely that your spoofed answer will be the first one to hit the server and thus poison the cache once the TTL for that TLD has expired. Spoofing responses from TLD servers is standard issue cache poisoning, and you cannot use it (any more) to poison a cache with an irrelevant record; BIND is going to ignore any NS, A, SOA, or other records for bankofamerica.com. in the additional or authoritative sections if the request was for some-domain-that-don't-exist.com. I'm back to where I was before; not seeing anything new here except a clever theoretical attack that would work much better if the TTLs for the TLD servers were on the order of minutes or hours rather than days. Either Halver guessed wrong, or the security community has been mislead about the severity of the issue.

Re:I thought this wasn't the X attack from Y..

[Rudd-O]

The severity is that you can submit your own glue records with the attack. You get to set what DNS server is queried for any second-level domain, get it?

Re:I thought this wasn't the X attack from Y..

[dnsfool]

Yes, but that doesn't help in an attack.

If I go make a bunch of links to abcd.bankofamerica.com, bcde.bankofamerica.com, and so on, my intention is to hijack www.bankofamerica.com.

www.bankofamerica.com is not a subdomain of abcd.bankofamerica.com, and thus, any glue related to it that is provided in the above queries should be ignored.

Follow?

BIND may not currently be doing "balliwicking" at this detail, but it should be, and patching it to do so should be rather trivial.

Re:I thought this wasn't the X attack from Y..

[flosofl]

The way I understood it is that by specify an "Additional" RR packaged with the bogus Reposnse RR. Once I finally get through with xxffgg.bankofamerica.com, I also get my "Additional" RR processed, which in this case would be to point www.bankofamerica.com to my own server. Since I have remained within the baliwick of bankofamerica.com, the change is accepted without reservation and poisons the cache (with an abnormally large TTL). Legitmate requests for www.bankofamerica.com would not go to the authoritative server until the TTL expired. It's actually kind of clever. It actually uses the original baliwick fix against itself. Of course with a *much* better RNG and random source ports, this attack becomes much more difficult. With DNSSEC it becomes damn near impossible.

Re:I thought this wasn't the X attack from Y..

[dnsfool]

Yes that's the right idea, but it seems that just changing this concept of a "balliwick" would solve the issue.

There's no legitimate need for your bogus "www.bankofamerica.com" RR to be accepted when you're asking about "xxffgg.bankofamerica.com."

It makes sense to accept it when you're simply asking about "bankofamerica.com"; that's how normal glue works, but you already have the information you need regarding the domain itself, so accepting more unsolicited information doesn't provide you with anything.

Servers only need glue when they're traversing the chain. Once they're at the level they need to be at, they should ignore any other records (glue or otherwise) that are sent.

Re:I thought this wasn't the X attack from Y..

[mrogers]

My ISP probably has long-TTL records for bankofamerica.com and www.bankofamerica.com, but I don't need to wait for them to expire. If I ask for 000000001.bankofamerica.com, my ISP's DNS server will recurse to bankofamerica.com's DNS server, which will return NXDOMAIN. Meanwhile I bombard my ISP's DNS server with fake responses, hoping to beat the real response. I probably fail, so I try again with 000000002.bankofamerica.com. Eventually I'll succeed, and when one of my fake responses is accepted I can replace the long-TTL records for bankofamerica.com and www.bankofamerica.com because they belong to the same domain.

Re:I thought this wasn't the X attack from Y..

[totally bogus dude]

Interesting... I don't think it's quite that easy though.

Let's say a client wants to know the address of www.cs.example.edu, so it asks the nameservers for example.edu

Being a large university, the cs subdomain is delegated to the CS department's name servers. For whatever reason, they're not actually under .cs, so the (legitimate) server sends back:

cs.example.edu IN NS compsci-ns1.example.edu
cs.example.edu IN NS compsci-ns2.example.edu
Additional:
compsci-ns1.example.edu IN A 1.2.3.4
compsci-ns2.example.edu IN A 1.3.4.5

Now, the query was for www.cs.example.edu, so the name servers are outside of bailiwick. We just ignore these records? Obviously not - we've just received a delegation to them, so knowing their addresses would be nice. Okay, so we drop any additional records unless they're providing us data we need, such as the addresses of name servers we've just received delegation info for?

But, what if an attacker knows we'll do that, and so it spoofs a reply:

www.cs.example.edu IN NS nasty.example.edu
Additional:
nasty.example.edu IN A 6.6.6.6

How does the resolver know this is an invalid response? It asked what it believes to be the authoritative nameserver for example.edu how to find www.cs.example.edu, and it's received a response delegating it to another server. It's also provided the address of that other server.

Let's get more interesting: we want to poison www.example.edu, after all. So maybe instead of our attacker feeding us a bogus name server for www.cs.example.edu, it just feeds us a bogus name server for example.edu:

example.edu IN NS nasty.example.edu
Additional:
nasty.example.edu IN 600000000000000 A 6.6.6.6

Okay, now we have an additional name server for the domain. With a really long TTL. Eventually we'll forget about the name servers, but this entry should remain for some time.

Not quite as easy as directly poisoning the target cache, but running a name server isn't difficult. We could also provide a name server in a different domain. It'll need to be properly delegated but registering domains isn't all that tricky.

Apple

[Phroggy]

Any idea when Apple might release a patch for Mac OS X Server?

I know compiling BIND from source is always an option, but most admins aren't going to do that.

Re:Apple

[Rudd-O]

Use DJBDNS.

Re:Apple

[Ice Station Zebra]

watch out, you my waken the "DJB is evil because someone told me so" people.

Re:Apple

[Phroggy]

If you can't administer it from Apple's Server Admin GUI, then it's not an option for most Mac admins. DJBDNS is probably great, but it's not a solution to this problem.

I'm not running Mac OS X Server myself, so it's not something I can fix.

Re:Been seeing this for a while

[snowgirl]

Only because someone marked it interesting.

This is not the same. The problem is sub-domains not super-domains.

Does going to your local University and registering mail.google.com.myuni.edu mean that you're going to get a lot of phishing? Yes, but only for people searching with myuni.edu as their default search domain. (likely, only on MyUni's internal network, and then only for people who aren't super-seasoned salt-cured security people who automatically type "mail.google.com." every time)

This problem is that in pining for xxxx.google.com you can potentially ADD information that "Hey! I know what mail.google.com is too!" Since the super-domains match up, the DNS servers would go "right then, update my cache."

Full post in my RSS feed

[joebeastie]

For what it is worth. I see the whole blog entry in my google reader rss feed for Matasano.

Hottest?

[Rudd-O]

This is sad.

Re:Hottest?

[Antique Geekmeister]

What's wrong? Doesn't your NNTP server carry alt.sex.bindage anymore?

Re:Hottest?

[Anonymous Coward]

This is sad.

Sad?!

This... Is... SLASHDOOOOOT!

Re:Hottest?

[kpainter]

I suspect a lot of Slashdotters have their sexual *ahem* attentions redirected to 127.0.0.1

Streisand Effect

[Samah]

I fail to see the point in pulling this information. The only people who will CARE about it are those who know how to exploit it, and they're the exact people who'll be able to find it regardless of if it's removed.
I wouldn't mind betting this will show up on Wikileaks pretty soon (if it's not already).
For those who've not heard of it: http://en.wikipedia.org/wiki/Streisand_effect

Re:Streisand Effect

[FlyingBishop]

Of course, the little caveat is that this was already big news... there was never any real consideration of stopping the release, just delaying it. And I think this may have bought people who were already preparing for it an extra hour to stay late tonight and patch, or shut down their servers to patch, while redirecting traffic for the evening.

Use djbdns (aka tinydns)

[Neanderthal Ninny]

Use djbdns which is immune to this attack. Dan Bernstein actually described this in 2002 http://cr.yp.to/djbdns/res-disaster.html

djbdns is not prefect but has been better than BIND which had it large share of bugs and security problems.

Re:Use djbdns (aka tinydns)

[Anonymous Coward]

That is not it.

Re:Use djbdns (aka tinydns)

[Antique Geekmeister]

The licensing on djbdns used to be pretty unacceptable, although it's gotten much better in the last few years. The packaging and documentation of djbdns and dan's other tools are awkward at best. Dan's software deliberately violates the UNIX File System Hierarchy, the 'daemontools' package he uses to run his software is extremely dangerous in most environments because it hands off control of daemons to non-root users, and ucspi-tcp is similarly nasty to package and maintain in a server environment without personnel to dedicate to manually integrating and patching Dan's codebase.

There are compelling reasons not to get caught up in Dan Bernstein's tools. While they're often technically brilliant, it's often easier and safer to transfer their critical features to a more manageable and installable code base.

Re:Use djbdns (aka tinydns)

[Kent Recal]

I'm not a djb fanboy but I have to counter one of your points:

the 'daemontools' package he uses to run his software is extremely dangerous in most environments because it hands off control of daemons to non-root users

How is handing off control of daemons to non-root users dangerous?
Djb goes a long way in terms of separation of concerns here, qmail for example runs with no less than seven different userids. Attacking Dan's software for a lack of security is a bit like preaching to the pope. Have you looked at his security track record recently?

I do agree with your other points, though, especially with the awkward packaging and the (past) licensing problems. I have recently converted from qmail to postfix because I got tired of the patching and so far I'm not missing anything.

It's a different story with dnscache/tinydns, though. I have still not found a viable replacement for these. It's not just the immunity to this recent exploit here, it's the whole design. Yes, dealing with daemontools is annoying at best. But dealing with the bind zones-format would be so much worse! The tinydns data format is a strike of genius. Until someone comes up with something comparable or just clones the format you'll have to pry djbdns from my cold, dead fingers...

Re:Use djbdns (aka tinydns)

[Antique Geekmeister]

Because handing control of daemons to such users is often done extremely badly and with convenience over security considered paramount, and those 'users' can swamp the systems' resources. I don't want casual users allowed to propagate demons, and the resources to run them, at whim in a shared environment. I want to make them think about it.

Re:Use djbdns (aka tinydns)

[Kent Recal]

Sorry, but you sound like you have no idea what you're talking about.
Read the qmail security guarantee (bullet 4 under "Why is qmail secure?") to get back on topic.

Re:Use djbdns (aka tinydns)

[Antique Geekmeister]

That's nice. I was talking about daemontools, not qmail. Now go look at that guarantee: by leaving out all the factors that Qmail has to tie to, such as NFS, authentication, denial-of-service attackets, etc., the guarantee is fairly meaningless in most environments.

Re:Use djbdns (aka tinydns)

[Kent Recal]

Your point is just as invalid when applied to daemontools.
Djb is well-known for being very anal about security and seperation of concerns on all fronts, which is part of the reason why parts of his software feel quierky to many. Thus your blanket statement "is often done extremely badly and with convenience over security considered paramount" simply makes no sense in the context of djbware. Where did he do any of that "badly" or prioritize convinience over security?

Re:Use djbdns (aka tinydns)

[r_cerq]

Sorry, but I'll have to disagree on the daemontools issue. Yes, it's a completely different way of thinking, but once you get used to it (and to ucspi-tcp), there's a lot of stuff that can be done with it...

All servers under my direct or indirect control have them installed as a rule (and we're talking a few hundred servers here), and most of them are actively using them.

Need a quick TCP-based daemon for menial tasks (like outputting a status line for monitorization?) tcpserver + supervise. A looping task? supervise that task, and add a sleep at the end of the run script. Don't want to write a logging function for some app? print to stdout/stderr, supervise it, and use multilog. ("free" log rotation and filtering included). Some sort of program that wasn't supposed to run as a daemon? fghack, supervise, multilog, and you're set. There's a lot of ways you can use those tools, you just have to remember they're there...

Re:Use djbdns (aka tinydns)

[Antique Geekmeister]

Lack of documentation, poor software packaging, and poor integration with other components created by Dan's former copyrights (which he's admittedly changed), and by Dan's refusal to follow basic system standards of user authentication, inventing his own personal unique malloc, replacing the standard system functionality with his own personal unique blend of unfriendly to manage, oddly laid out software, etc.

Re:Use djbdns (aka tinydns)

[Kent Recal]

Ehm, I see you have an axe to grind with djb or how come you spill this unrelated rant, completely ignoring my question? None of your points are security related. In fact, some of them (malloc, "odd layout") are due to him striving for better security. Oh, and lack of documentation... Have you even looked at http://cr.yp.to/ - ever?

Anyways, I'm writing you off as a troll now. Maybe you think it's some kind of geek-chique to rant against djb these days but please, at least get a basic understanding first.

Re:Use djbdns (aka tinydns)

[Antique Geekmeister]

I responded to your original post, included below:

> Use djbdns which is immune to this attack. Dan Bernstein actually described this in 2002 http://cr.yp.to/djbdns/res-disaster.html [cr.yp.to]
>
> djbdns is not prefect but has been better than BIND which had it large share of bugs and security problems.

While djbdns is immune to this attack (good for Dan!), 'better than BIND' has to include a lot more than merely security. It has to include managability, configurability, documentation, packaging, etc. And djbdns reliance on daemontools creates an additional set of issues, including some significant security ones due to the non-root management of daemons and its frequent mishandling.

Re:Use djbdns (aka tinydns)

[Kent Recal]

I really wonder if you're incapable or just unwilling to understand. You have lost this argument long ago because you're not making a point!

Well, but if you so want I will iterate again:

There is no "frequent mishandling" in the "non-root management of daemons" in either daemontools or djbdns. Please quote your "significant security issues" with that because to my knowledge there have been no security issues with djbdns ever. Also please define your term "mishandling"?

Remember, one of the design goals for djbdns was to provide a more secure alternative to the horror that is BIND. According to its security track record it succeeded so far.

Furthermore djbdns is considered by many to be *much* more managable and configurable than BIND. Just compare the configuration mess in BIND (especially the awkward zones format) to the data-format in tinydns that I quoted in my earlier mail. Ultimately this boils down to taste and preference but in no case is it a point to be made against djbdns - much rather one to be made against BIND. Just ask some people who have used both (I have).

Documentation? Again?
Djbdns comes with an exhaustive manual and a truckload of community documentation.

So what remains of your argument? The packaging. We can agree on that but that has nothing to do with security and is probably not the driving factor when choosing an DNS impl.

PS: Work on your reading comprehension. The post you replied to was not mine and the statement "better than bind" that you pulled out of context clearly compared the two on the basis of security problems and bugs, in the same friggin' sentence! That seems like a reasonable assertion to make when comparing djbdns (zero bugs, zero security issues) to BIND (an emberassing number of bugs and security issues), don't you think?

Re:Been seeing this for a while

[loxosceles]

Mod parent down for not understanding the vulnerability.

Re:wow

[Anonymous Coward]

they don't know shit unless it's in a fag comic book or a dungeons and dragons guide.

and your point is???

Re:Been seeing this for a while

[0xygen]

That is different - that's just advertising and silliness off the way the wildcard matching works for WHOIS.

The issue is when you can force the target to resolve blah.google.com to poison www.google.com and then include a glue response for www. in with the blah. response which is then accepted because the domains match at to the right of that level.

Was that it?

[mrbah]

For all the hype, this attack is hardly groundbreaking. It strikes me as something that was used to coerce vendors into finally patching smaller flaws security people have been nagging about for years.

url

[Anonymous Coward]

For those who want to read this here is the url. http://blogs.buanzo.com.ar/2008/07/matasano-kaminsky-dns-forgery.html

The register.

[smoker2]

There is a write up on the register that suggests that while this may be Kaminskys attack, there is a possibility that it is another separate vulnerability.

Better Speculation

[logicnazi]

Alright, so I'm not even someone who does DNS/networking stuff even for a hobby (just a math grad who skimmed the RFCs once or twice) so if I can figure this out from what's up now then any competent bad guy can as well.

Anyway my guess is that it involves a combination of the birthday attack and the request for multiple nonexistant nameservers. That is as the attacker you trick poisontarget.com into trying to resolve the following locations.

AAA.google.com
AAB.google.com ....
XXX.google.com

Now you forge a single response packet that works for all of these requests and send many different copies with different TXIDs. Thus to succeed you need only hit ONE of the TXIDs used in the real requests.

In these forged responses you also have a forged glue record (as suggested in some of the links) which gives you control of lookups for all of google.com at poisiontarget.com after a single success.

Then again maybe I missed something basic which means this doesn't work.

Re:Better Speculation

[zero1101]

This is exactly it, nice summary. Not sure why you're not +5 yet.

Re:Better Speculation

[dnsfool]

As I mentioned above, this still doesn't make any sense. Let's look at just what a glue record is and how they are designed to work.

In this example, we're trying to resolve aaa.google.com on a fresh recursive nameserver with no cache. The first thing it will do is make a request out to the root nameservers. The root name servers will respond saying basically "I don't know anything about aaa.google.com, the closest I can get is simply .com.. Here are the nameservers for .com."

The root servers send you no RRs in the answer section, 12 NS RRs in the authority section (the GTLD servers responsible for .com), and 12 A RRs in the additional section with the IP addresses of the NS RRs.

Those A records in the additional section are the glue records. The data they have is crucial to the functioning of DNS; you can't ask the GTLD servers about google.com if you can't get to them.

The same thing happens at the next stage; when you ask the GTLD servers about google.com, you get a response that's basically identical except this one has the NS and corresponding A records for google.com, rather than .com itself.

Again, these records are crucial. You can't ask ns1.google.com about aaa.google.com unless you know the address of ns1.google.com.

However, this is where the attack breaks down.

When you ask ns1.google.com for the address of aaa.google.com., a valid response RR can only be one of three things:

1. A normal RR for aaa.google.com such as an A record or CNAME.

2. A delegation referral that indicates aaa.google.com is a subdomain, with more glue records pointing to something like ns1.aaa.google.com.

3. An NXDOMAIN respose indicating that aaa.google.com doesn't exist, with a single RR in the authority section -- the SOA for all of google.com.

Any record appearing for "www.google.com" is totally irrelevant and any responsible DNS server should discard it without thinking.

The single attack vector I can see is if you are returned a bogus delegation (faking a subzone); e.g., your faked response has a single RR in the authority section that says "aaa.google.con IN NS www.google.com" and a single RR in the additional section that says "www.google.com IN A evil.haxor.ip.addr"

However, that A record should not be cached and definitely should not displace an existing RR for www.google.com if one exists; it is not authoritative.

With this type of spoofed response, you would connect to evil haxor's IP address and once again ask for aaa.google.com and possibly get an address or some other garbage, but anything you get at this point must only be 'trusted' if it applies to the 'aaa.google.com' zone, which 'www.google.com' is not a part of.

I hope I'm making this more clear this time around. The net of this is that with a little intelligence in the DNS server, vulnerability to this attack is nonexistant, because it relies on the victims DNS server to cache irrelevant results, or results that are only relevant in the context of that query and no others.

If after this attack takes place against your nameserver, you attempt to go to www.google.com, the nameserver should be asking ns1.google.com all over again, and not simply trusting the irrelevant address it received when trying to get to aaa.google.com.

Re:Better Speculation

[dnsfool]

I also have to say that I don't believe the extremely contrived example I came up with is entirely valid. By definition, the NS records and their associated glue must (should? Have to check the RFCs) exist within the delegated zone.

In other words, glue records for "aaa.google.com" should only be valid if they exist within "aaa.google.com" e.g. ns1.aaa.google.com.

If the RFCs don't say this, I don't think it would be too difficult to get such an update through the system, since every legitimate subzone I've encountered operates within these rules anyhow.

Re:Better Speculation

[Anonymous Coward]

Wow, so only hours after the full details were published, and after it was clearly explained in a comment posted just 2 hours before yours, you were able to "guess" what the problem was. Bravo!!!

You can read it here

[Dramacrat]

http://beezari.livejournal.com/141796.html Ahhh, internet. (Not my journal, nor can I vouch for the veracity of the post-- but it seems to fit with other fragments posted and found)

Nasty tactic

[Todd Knarr]

The described attack's a nasty tactic. I hadn't thought of it, or rather I had but discarded it under the impression that all DNS software had changed years ago to filter out additional RRs that weren't responsive to the actual query to prevent exactly this sort of attack. I hope Dan's patches include such a filter.

Overkill

[Tubal-Cain]

Frankly, we should just do away with the subject line entirely.

Or /. could stop adding the Re:*'s for people and force them to type something.

Re:wow

[Anonymous Coward]

what? are you one of those fags that like to get pounded up the ass by your dungeon master? do you suck dicks thinking about clark kent? fag.

FAIL

[Anonymous Coward]

You fail at life.

Copy of DNS exploit details

[Anonymous Coward]

http://blogs.buanzo.com.ar/2008/07/matasano-kaminsky-dns-forgery.html

It's okay...

[davidu]

There will be more (new) announcements in the coming week or two. The DNS is gonna be fun for a while, unfortunately. We prefer it to be reliable and accurate.

GoogleReader caching FTW

[Anonymous Coward]

y ecopeland
0.

The cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan Kaminsky will announce at Black Hat.
1.

Pretend for the moment that you know only the basic function of DNS -- that it translates WWW.VICTIM.COM into 1.2.3.4. The code that does this is called a resolver. Each time the resolver contacts the DNS to translate names to addresses, it creates a packet called a query. The exchange of packets is called a transaction. Since the number of packets flying about on the internet requires scientific notation to express, you can imagine there has to be some way of not mixing them up.

Bob goes to to a deli, to get a sandwich. Bob walks up to the counter, takes a pointy ticket from a round red dispenser. The ticket has a number on it. This will be Bob's unique identifier for his sandwich acquisition transaction. Note that the number will probably be used twice -- once when he is called to the counter to place his order and again when he's called back to get his sandwich. If you're wondering, Bob likes ham on rye with no onions.

If you've got this, you have the concept of transaction IDs, which are numbers assigned to keep different transactions in order. Conveniently, the first sixteen bits of a DNS packet is just such a unique identifier. It's called a query id (QID). And with the efficiency of the deli, the QID is used for multiple transactions.
2.

Until very recently, there were two basic classes of DNS vulnerabilities. One of them involves mucking about with the QID in DNS packets and the other requires you to know the Deep Magic.

First, QIDs.

Bob's a resolver and Alice is a content DNS server. Bob asks Alice for the address of WWW.VICTIM.COM. The answer is 1.2.3.4. Mallory would like the answer to be 6.6.6.0.

It is a (now not) secret shame of mine that for a great deal of my career, creating and sending packets was, to me, Deep Magic. Then it became part of my job, and I learned that it is surprisingly trivial. So put aside the idea that forging IP packets is the hard part of poisoning DNS. If I'm Mallory and I'm attacking Bob, how can he distinguish my packets from Alice's? Because I can't see the QID in his request, and the QID in my response won't match. The QID is the only thing protecting the DNS from Mallory (me).

QID attacks began in the olden days, when BIND simply incremented the QID with every query response. If you can remember 1995, here's a workable DNS attack. Think fast: 9372 + 1. Did you get 9372, or even miss and get 9373? You win, Alice loses. Mallory sends a constant stream of DNS responses for WWW.VICTIM.COM. All are quietly discarded --- until Mallory gets Bob to query for WWW.VICTIM.COM. If Mallory's response gets to your computer before the legitimate response arrives from your ISP's name server, you will be redirected where Mallory tells you you're going.

Obvious fix: you want the QID be randomly generated. Now Alice and Mallory are in a race. Alice sees Bob's request and knows the QID. Mallory has to guess it. The first one to land a packet with the correct QID wins. Randomized QIDs give Alice a big advantage in this race.

But there's a bunch more problems here:

*

If you convince Bob to ask Alice the same question 1000 times all at once, and Bob uses a different QID for each packet, you made the race 1000 times easier for Mallory to win.
*

If Bob uses a crappy random number generator, Mallory can get Bob to ask for names she controls, like WWW.EVIL.COM, and watch how the QIDs bounce around; eventually, she'll break the RNG and be able to predict its outputs.
*

16 bits just isn't big enough to provide real security at the traffic rates we deal with in 2008.

Your computer's resolver is probably a stub. Which means it won't really save the response. You

Even worse...

[AySz88]

According to the "confirmed" post by Thomas Dullien aka Halvar Flake (found via this PCWorld article), the problem might be even simpler than that. He issues requests for some non-existent domain in .com, instead of a non-existent subdomain in the domain you're attacking. Can anyone confirm, or must it be subdomains?

Re:Even worse...

[totally bogus dude]

Well that would work, although since VeriSign's "SiteFinder" stunt some DNS servers (including bind) have an option to denote a zone as being "delegation only" zone, which would stop this attack from working. I don't know how widespread use of this option would be, though.

Assuming it's not, than poisoning .com would make it much easier: with one successful attack you could poison dozens of popular domains.

What could be interesting is combining this attack with zombies -- that way you don't need to trick a user into visiting a site with your links on it, you can just spam the ISPs name servers from one (or several) of their clients until you finally get lucky. Even better, the larger the ISP the more likely one of your randomly infected zombies will be within their network.

You could also have the ISP name server do some queries against a DNS server you control so you can look for any patterns in the query IDs and source ports, and use that information to narrow the search space for your actual attack.

I'm not really seeing any solutions to these attacks that don't simply turn it into an easy DoS. Fun times are ahead!

Re:Even worse...

[totally bogus dude]

Wow, the grammar in that post really sucks. Sorry.

Re:Even worse...

[makomk]

Nope, apparently it has to be a subdomain of the domain you're attacking, due to bailwick filtering - see, for example this post. If it wasn't for bailwick filtering, an attacker could just launch a request to a DNS server they controlled and avoid having to guess anything. (Supposedly, this used to work, though.)

I have the whole thing reasonably well formatted

[FoxNSox]

See http://thefrozenfire.com/data/dnspoisoning.html for the whole deal, without the pastebin RAW formatting ;)

Re:Been seeing this for a while

[Anonymous Coward]

Parent may be off-topic, but it's still interesting.

Useful info for the paranoid

[AySz88]

Kaminsky posted a test to see whether your DNS server is still vulnerable (it seems that you'll need to allow scripts from toorrr.com). If the server is vulnerable, he appears to be recommending OpenDNS as a stopgap measure. Their nameservers are 208.67.222.222 and 208.67.220.220 .

If you're really paranoid, switch to OpenDNS first before running the test...

On a related note, doxpara.com = 66.240.226.139 , but I can't get anything but a 404 at the IP address. Should I be nervous?

Re:Useful info for the paranoid

[leuk_he]

You should be nervous.

All leading internet companies that control the internet software came together at Redmond (why there) to patch their software and release it at the same time.

Then they keep the exact detail hidden, blabbing something about about making the port dns request come from random.

And the moment the information looks like to appear, it is hidden again.

The patch released only affected independent firewall makers (like zonealarm) who were kept out of the circle.

Do you realize they just gave all udp traffic a free network neutrality "pass free our shaper".
Because any port can be a dns request "the core of the internet".

And now these internet software makers are put together, for some make believe vulnerability. (egress filtering would have solved it also and fixed other problems also) , they will be force to make additional security fixes (to fight childporn/terrorist/extremist/spam) in an other 15 months

YOu can call me paranoid, and i like to keep it that way. You would be paranoid too if the whole world was against you.

Full Text of Article Here

[hivbus]

I've posted up the full text of the article, and it'll stay up, assuming lighty doesn't fail miserably on me. http://www.jbip.net/content/text-mantasanos-article-detais-kaminskys-dns-attack

Subject lines tell me how to mod

[KWTm]

Frankly, we should just do away with the subject line entirely. They generally just get filled with "Re:Re:Re:Re:Unoriginal First comment" anyways. It serves no purpose in a system like slashdot's, and causes things like the above.

Interesting you say that. Whenever I get mod points, the subject line is one of the things I look at to see where to grant my mod points.

Reading every posting to see which ones are worth modding up would be too much work. I look for replies in a thread where the author has taken the effort to change the subject line from "Re:Re:Re:Re:Unoriginal First comment" to something relevant; these have a much higher chance of being insightful or interesting. The more concise and pithy the subject, the more I make sure I click on it to read; a subject line like "Not true: ABC is counterexample" conveys more information than "You're wrong!" and is correspondingly more likely to be modded up.

I'm not saying that a catchy subject line is enough to get mod points from me, but those are the ones I will read first.

Re:Been seeing this for a while

[Alsee]

Mod parent down for not understanding

YMBNH.

-

Full Disclosure was in 2005, jeez!

[weasel5i2]

http://www.sans.org/reading_room/whitepapers/dns/1567.php

Re:Full Disclosure was in 2005, jeez!

[weasel5i2]

OK, i shoulda RTFA first, it isn't the same attack.. Kinda similar, and just as evil.. Apparently the strength of both attacks is in the process of sending a FLOOD of spoofed packets and hope that just one of them makes it through in the correct sequence. Eeeevil.

Re:I have the whole thing reasonably well formatte

[Chrisq]

reasonably well formatted .... except for the white-on black colour scheme. Makes me nostalgic for those 1980s CRTs.

Ptacek eats shit

[Anonymous Coward]

And here's tptacek's grovelling retraction (which followed his drunken rant on DD at the weekend which firmly argued the public have the right to know and trying to stop public discussion is Wrong). I fear the Matasanto crew and Halvar are about to discover what happens when geeks allow their 'satiable curtiosity to run away with their sense of ethics. Halvar in particular posted a long self-justification (with mathematical functions!) trying to prove that public dissemination before BlackHat would be a good thing.

=== BEGIN PTACEK ===

"Earlier today, a security researcher posted their hypothesis regarding Dan Kaminskyâ(TM)s DNS finding. Shortly afterwards, when the story began getting traction, a post appeared on our blog about that hypothesis. It was posted in error. We regret that it ran. We removed it from the blog as soon as we saw it. Unfortunately, it takes only seconds for Internet publications to spread.

We dropped the ball here.

Since alerting the Internet earlier in July about the upcoming announcement of his finding, Dan has consistently urged DNS operators to patch their servers. We confirmed the severity of the problem then and, by inadvertantly verifying another researcherâ(TM)s results today, reconfirm it today. This is a serious problem, it merits immediate attention, and the extra attention itâ(TM)s receiving today may increase the threat. The Internet needs to patch this problem ASAP.

Dan told me about his finding personally, in order to help ensure widespread patching before further details were announced at the upcoming Black Hat conference. We chose to have a story locked and loaded for that presentation, or for any other confirmed public disclosure. On a personal level, I regret this as well.

Dan did phenomenal work on this research. It was impossible to talk to him today and not know that he was sincere about coordinating a graceful disclosure and fix for the problem. That I helped detract from that work is painful both personally and professionally, and I apologize to Dan for the way this played out.

Thomas Ptacek

Principal, Matasano Security

Jul 21, 2008

Mirror of the pulled post available!

[darkoz]

A complete mirror of the original text @ matasano.com has been posted here

http://darkoz.com/?p=15

Enjoy!

Don't use Bind

[Nicolas MONNET]

Bind is evil, bind has the worst security track record except maybe for sendmail but that's not saying much.
I don't know much about the other options, I use djbdns, but PowerDNS looks fine.

Re:Don't use Bind

[Anonymous Coward]

BIND 9 was a complete rewrite, and has a decent security record.

Re:Don't use Bind

[Phroggy]

If you can't administer it from Apple's Server Admin GUI, then it's not an option for most Mac admins.

Weird claims

[Nicolas MONNET]

1. Licence

2. With possibly the exception of qmail, you can put everything anywhere you like. The /service path location is only hardcoded in svscan, for instance, and the other weird paths such as /command are only used in the install scripts, which you probably don't want to use anyway.

3. I wish there was a credible alternative to djbdns. I only know of PowerDNS, haven't had time to try it yet, what about the others? Bind is a non-starter for me, just like sendmail (but Postfix is ok).

Okay quick question.

[ledow]

Okay, I don't dabble deep in DNS but I have a few quick questions. The RR thing is nasty because sub-domain authority implies domain authority. That's just silly and I'm stunned that something so simple is still true. I imagine there are a million and one "good" reasons for it, but it appears to be a gaping hole that could easily have been removed.

However, on the "let's spoof a DNS response" front - if a DNS server/client is being sent lots of spoof reponses, how long until they are picked up by a filter and blacklisted, tarpit'd or similar at the ISP end? This is the solution surely, even if you can send millions of packets with incorrect QID's and similar identifiers at a DNS server, like any other service at some point it has to say "you're trying to be naughty" and blacklist any packets, sound an alert, get the upstream filters to block such traffic etc. (This is, of course, assuming that there are at least some systems in place to stop or limit source-IP forgery in the first place). It might even be a good idea, at this point, for such servers to not trust their data, and constantly compare their copies with those available from the nameservers. If "fluctuation" of the data (between real and spoofed responses) is detected, then sound an alert on that domain.

How many responses does an average DNS server get that are invalid because of purely accidental causes (e.g. corrupted packets, mis-configured routers etc.)? Surely it's so few that it can instantly blacklist any suspicious activity, like trying to poison recursive caches in this manner.

I imagine that most home routers are extremely stupid and can't stop such things because they rely almost exclusively on the ISP's DNS servers to do their job and a flood of fake packets will not be picked up (this is, however, one of the reasons that I've always used "DMZ" or PPP half-bridge settings on ADSL routers to throw all external packets towards a real server rather than relying on some VxWorks firmware to handle IP-based attacks). But the servers? They *should* be filtering, cleansing and blacklisting packets even before you get into whether they have the most up-to-date patches, and a security fix to enhance the randomness of X etc.

It seems that the DNS servers are too trusting of "correct" packets that come as part of packet-floods of incoming data that is *obviously* false. DNS clients accepting data appearing to come from a trusted host is not nice, I agree, but recursive DNS servers should know better.

Or have I missed something incredibly obvious here?

I don't really care because my ISP wasn't vulnerable to this attack when I first tested it about 10 minutes after the first posting about its potential on the blog, and I'm pretty sure that they wouldn't have had any more advanced warning than anyone else.

Having said that, the DNS servers provided by LGfL's broadband supplier are, apparently, vulnerable. (London Grid for Learning, a London-wide schools extranet that virtually every London school, of which there are hundreds, use for their Internet connection, DNS servers, content filtering, etc. as well as their external content host). But, knowing LGfL and the way UK IT operations that are in any way involved with government work, that's not surprising at all.

Re:Okay quick question.

[Anonymous Coward]

Or have I missed something incredibly obvious here?

Yes, the "obviously" false packets are dropped anyway, because their QIDs, port numbers or addresses don't match the request. The packets which get through are not obviously false. In other words: A DNS server may be able to detect that it is being attacked, but that doesn't help much, because it already filters all packets which it can identify as malicious packets.

Re:Okay quick question.

[dnsfool]

For the record, having good source port randomization does not make you immune, it just makes you resistant.

Using the attack as described, you go to some web forum and post image links as urls 1.yourbank.com to 50000.yourbank.com.

As soon as you post, you start blasting joes (a frequent reader of the forum) dns server with fake responses The chances are actually pretty good that you'll eventually get a match in a short period of time.

That is the 'birthday' part of the attack.

Sending 50,000 packets with forged random source ports and query ids to hit a collision in a 32bit (combined) field, you'll match up one time in four.

That's better than one time in one, and you still have to 'beat the clock', but if you do this with a simultaneous ddos against the legit nameservers for mybank.com, your chances increase dramatically.

Re:Okay quick question.

[Anonymous Coward]

I also only dabble in this DNS stuff, but I also have paid close attention to this issue, and most of your questions have been answered, so I'll repeat the answers in-line.

...The RR thing is nasty because sub-domain authority implies domain authority. That's just silly and I'm stunned that something so simple is still true. I imagine there are a million and one "good" reasons for it, but it appears to be a gaping hole that could easily have been removed.

That's not silly, that's how it was designed, and for very good reason. You're not assuming sub-domain authority. If I query abc.google.com, I'm not asking for a subdomain, I'm asking for the host. Therefore, the nameserver responsible for abc.google.com should also be authoritative for www.google.com, shouldn't it? DNS is arguably the most heavily relied on protocol on the Internet, and so it is designed to be efficient. In order to allow for quick failover when problems occur, they allow you to add in-bailiwick records. This is perfectly reasonable, because if you're asking ns.google.com for the record for abc.google.com, then you have every reason to believe what it has to say about abc.google.com AND www.google.com.

It should also be noted that the really big bad problem here isn't that you can hijack a host, it's that you can hijack a domain. So it's not a case of the bad guy saying "hey, I know that you asked for abc.google.com, but let me also tell you about www.google.com", it's the bad guy saying "hey, I know that you asked for abc.google.com, but I know nothing about that domain, and for all your google.com requests, you'd be better of asking ns.google.com, and by the way you can reach him at my.ip.add.ress". I think this is the thing that is sometimes lost in these discussions. Everyone seems to be talking about just the host-hijacking problem.

However, on the "let's spoof a DNS response" front - if a DNS server/client is being sent lots of spoof reponses, how long until they are picked up by a filter and blacklisted, tarpit'd or similar at the ISP end?...

Yes, if ISP's had instant flood detection and response, this would be fine. But they don't. Yes, it's easy to detect, it's a 5-10 second (on a high-speed connection) blast of packets with invalid QIDs. Of course it relies on some sort of firewall that keeps track of every single outgoing DNS query, and matches the QIDs on the responses (read huge overhead for ISPs), or it relies on a whole bunch more code being added to DNS servers to keep track of bad responses, and then do something (what do they do, how is it managed, do we want to add a bunch more code to BIND? how many security bugs will be introduced just implementing this).

So you're right, it's easy for me to describe how to detect it. But it's not easy to mitigate. If it was, then ISPs would be doing that, and they're not.

Or have I missed something incredibly obvious here?

No, you haven't missed anything obvious. The solutions just aren't as easy as you make them sound. DNS is the most widely relied on protocol on the Internet, and so we can't just go changing how it works. Experts in the field have explicitly said that ever removing this whole trusted in-bailiwick thing would likely break everything. I think that really smart people are working on these systems, and if they say that it's not easy to fix these problems, then I'd have to go with the experts.

Leaked report is mirrored here

[Anonymous Coward]

http://digitalconsumption.com/forum/634-DNS-Bug-Leak

Re: Authoritarian Followers suck

[Anonymous Coward]

"If DNSSEC is such ajoke, then how do you explain it being the standard? Or do you propose that the IETF is a joke also?"

Please, DJB and others have written extensively on how the DNS related RFCs are pushed through by a bunch of BIND supporters and how poorly thought out and product-centricly they have been written. DNS SEC RFCs are primary examples, how many times are they going to put out new DNS SEC standards after they are shown to be deeply flawed? Let's stop going down the DNS SEC road to satisfy Paul's ego and start from a clean slate. He and his succubuses have been proven wrong on dns security issues time and times again by the guys they have fought a PR war against - DJB and others.

Nothing would wound Paul's ego more than to list the ways in which DJB has been shown to be right and he has shown to be wrong over the years.
 
Even on an issue as seemingly obvious as running an auth and a caching dns server as separate processes, the ISC related attack dogs hounded DJB relentlessly until Nominum said "the performance of BIND 9 (which we at Nominum wrote, BTW) sucks. So our server that we wrote after learning from our mistakes that we made on BIND 9, uses a separate process for auth and caching dns servers, just like DJB did all those years ago."

http://home.cc.umanitoba.ca/~altemey/

This was disclosed in 2004

[Anonymous Coward]

RFC3833, available here:

http://www.ietf.org/rfc/rfc3833.txt

is a threat analysis of the DNS system, and disclosed this vulnerability in 2004 (in section 2.2).

Dan J. Bernstein alerted the DNS community to this in 2001:

http://cr.yp.to/djbdns/forgery-cost.txt
http://cr.yp.to/djbdns/forgery.html

So why all the fuss on who said what and when last week? This is very old news.

I nabbed it yesterday

[Anonymous Coward]

Here is the blog post:

0.

The cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan Kaminsky will announce at Black Hat.
1.

Pretend for the moment that you know only the basic function of DNS â" that it translates WWW.VICTIM.COM into 1.2.3.4. The code that does this is called a resolver. Each time the resolver contacts the DNS to translate names to addresses, it creates a packet called a query. The exchange of packets is called a transaction. Since the number of packets flying about on the internet requires scientific notation to express, you can imagine there has to be some way of not mixing them up.

Bob goes to to a deli, to get a sandwich. Bob walks up to the counter, takes a pointy ticket from a round red dispenser. The ticket has a number on it. This will be Bob's unique identifier for his sandwich acquisition transaction. Note that the number will probably be used twice â" once when he is called to the counter to place his order and again when he's called back to get his sandwich. If you're wondering, Bob likes ham on rye with no onions.

If you've got this, you have the concept of transaction IDs, which are numbers assigned to keep different transactions in order. Conveniently, the first sixteen bits of a DNS packet is just such a unique identifier. It's called a query id (QID). And with the efficiency of the deli, the QID is used for multiple transactions.
2.

Until very recently, there were two basic classes of DNS vulnerabilities. One of them involves mucking about with the QID in DNS packets and the other requires you to know the Deep Magic.

First, QIDs.

Bob's a resolver and Alice is a content DNS server. Bob asks Alice for the address of WWW.VICTIM.COM. The answer is 1.2.3.4. Mallory would like the answer to be 6.6.6.0.

It is a (now not) secret shame of mine that for a great deal of my career, creating and sending packets was, to me, Deep Magic. Then it became part of my job, and I learned that it is surprisingly trivial. So put aside the idea that forging IP packets is the hard part of poisoning DNS. If I'm Mallory and I'm attacking Bob, how can he distinguish my packets from Alice's? Because I can't see the QID in his request, and the QID in my response won't match. The QID is the only thing protecting the DNS from Mallory (me).

QID attacks began in the olden days, when BIND simply incremented the QID with every query response. If you can remember 1995, here's a workable DNS attack. Think fast: 9372 + 1. Did you get 9372, or even miss and get 9373? You win, Alice loses. Mallory sends a constant stream of DNS responses for WWW.VICTIM.COM. All are quietly discarded â"- until Mallory gets Bob to query for WWW.VICTIM.COM. If Mallory's response gets to your computer before the legitimate response arrives from your ISP's name server, you will be redirected where Mallory tells you you're going.

Obvious fix: you want the QID be randomly generated. Now Alice and Mallory are in a race. Alice sees Bob's request and knows the QID. Mallory has to guess it. The first one to land a packet with the correct QID wins. Randomized QIDs give Alice a big advantage in this race.

But there's a bunch more problems here:

*

If you convince Bob to ask Alice the same question 1000 times all at once, and Bob uses a different QID for each packet, you made the race 1000 times easier for Mallory to win.
*

If Bob uses a crappy random number generator, Mallory can get Bob to ask for names she controls, like WWW.EVIL.COM, and watch how the QIDs bounce around; eventually, she'll break the RNG and be able to predict its outputs.
*

16 bits just isn't big enough to provide real security at the traffic rates we deal with in 2008.

Your computer's resolver is probably a stub. Which means it won't r

Subject line can be useful

[DragonHawk]

Frankly, we should just do away with the subject line entirely. They generally just get filled with "Re:Re:Re:Re:Unoriginal First comment" anyways. It serves no purpose in a system like slashdot's, and causes things like the above.

While it does seem that most people don't bother with the subject line, that's not everyone.

http://it.slashdot.org/~DragonHawk/

Re:Subject line can be useful

[Zebedeu]

Also anoying: people who don't use the signature facility and instead sign their messages manually so that others have no choice but to read them.

Spoofed source address

[DragonHawk]

if a DNS server/client is being sent lots of spoof reponses, how long until they are picked up by a filter and blacklisted, tarpit'd or similar at the ISP end?

DNS is UDP, these attacks assume a spoofed source address. So the responses are relatively hard to distinguish from legitimate responses. You could do deep packet inspection to try and recognize an attack heuristically, but that would be rather demanding from a CPU/memory standpoint. Keep in mind that big, busy caching resolvers can be answering tens of thousands of queries per second.

Blocking closer to the spoofing source sounds like it might work. But that didn't work for the spam problem. I don't expect it would work any better for this.

Throw in a bot net, and it becomes hard to isolate the source.

I don't see this as a trivial problem.

BIND rewrites

[DragonHawk]

lied about BIND8 and BIND9's complete rewrites,

Got a source I can check? (Or, to use the Wikipedia flavor, "Citation needed".)

I'm honestly curious.

Re:BIND rewrites

[mrsbrisby]

"The only way to support all of the new DNS protocol enhancements was to totally rewrite BIND.

BIND version 9 is a major rewrite of nearly all aspects of the underlying BIND architecture.

Re:BIND rewrites

[DragonHawk]

Sorry, I guess I should have been more explicit. I have seen the claims that BIND v9 was a major rewrite. What I haven't seen are (1) claims that BIND 8 was a major rewrite, or (2) evidence that BIND v9 wasn't a major rewrite. Those are both new claims to me.

As for my own investigation, I know, looking at the security advisory history for BIND, there have continued to be a steady stream of vulnerabilities due to implementation errors found in BIND 4 and 8, but very little due to implementation errors in BIND 9. (I'm considering CERT VU#800113 and similar to be design errors, which a rewrite wouldn't fix.)

I'm somewhat willing to forgive the BIND people for certain things, but an outright lie would be another matter entirely.

Re:BIND rewrites

[mrsbrisby]

Sorry, I guess I should have been more explicit. I have seen the claims that BIND v9 was a major rewrite. What I haven't seen are (1) claims that BIND 8 was a major rewrite, or (2) evidence that BIND v9 wasn't a major rewrite. Those are both new claims to me.

That's all right. It should have been parsed as:

• That's from the guy who lied about BIND 8
• That's from the guy who (made) BIND 9 a complete rewrite

BIND 9 was a major rewrite, but not that a major rewrite is a good thing. Completely rewriting your code base is generally considered bad. A majority of BIND 4 and BIND 8 vulnerabilities could have been fixed by mandating chroot, no-root, port randomization, and separate cache+content servers.

BIND 4 was a mere 10,255 lines, but BIND 8 is over 58,288 lines. Of course, it's more fun to simply load it into git and compare the two versions of the named directory- the patch is 20,548 lines changed alone.

BIND8 wasn't insecure because of "design flaws", or because "it was too complicated", or because "it was written in a different time by different people", but because it was written by people who frankly weren't very good programmers.

Paul is a very smart guy, but a lot of the problems with BIND are simple overengineering and complexity issues.

As for my own investigation, I know, looking at the security advisory history for BIND, there have continued to be a steady stream of vulnerabilities due to implementation errors found in BIND 4 and 8, but very little due to implementation errors in BIND 9. (I'm considering CERT VU#800113 and similar to be design errors, which a rewrite wouldn't fix.)

Except, other nameservers don't have the vulnerability.

The ADDITIONAL-section processing has been the root cause of almost all poisoning attacks. DNS caches that don't have additional-section processing have always been immune.

I'm somewhat willing to forgive the BIND people for certain things, but an outright lie would be another matter entirely.

I'm not. The BIND group has made a number of enormous design errors over the years that have been defended by hubris and ego. I don't trust them at all.

• 2001.01.29 23:25:06, Paul Vixie*, on bsdi-users: ``See BIND9. Written by a new team, sharing no code with BIND8. Two years in the preparation. 6+ months of testing. ... BIND9 is a complete rewrite by completely different (read: better) people.'' (In fact, the team was not ``completely different.'')
• 2001.02.04 06:32:01, Paul Vixie*, on bind-members: ``We've spent more than $2.5M on BIND9, which is a complete rewrite, and which took a dozen senior or supersenior DNS software experts over two years to complete.''
• Finally, at least Michael Graff worked on both BIND 8 and BIND 9

Ignore for a moment that the claim was wrong, and just bask in the stupidity of the claim that the super senior DNS software experts had never written a name server before (because they didn't work on BIND 4 or BIND 8).

text

[Anonymous Coward]

0.

The cat is out of the bag. Yes, Halvar Flake figured out the flaw Dan Kaminsky will announce at Black Hat.

1.

Pretend for the moment that you know only the basic function of DNS â" that it translates WWW.VICTIM.COM into 1.2.3.4. The code that does this is called a resolver. Each time the resolver contacts the DNS to translate names to addresses, it creates a packet called a query. The exchange of packets is called a transaction. Since the number of packets flying about on the internet requires scientific notation to express, you can imagine there has to be some way of not mixing them up.

Bob goes to to a deli, to get a sandwich. Bob walks up to the counter, takes a pointy ticket from a round red dispenser. The ticket has a number on it. This will be Bobâ(TM)s unique identifier for his sandwich acquisition transaction. Note that the number will probably be used twice â" once when he is called to the counter to place his order and again when heâ(TM)s called back to get his sandwich. If youâ(TM)re wondering, Bob likes ham on rye with no onions.

If youâ(TM)ve got this, you have the concept of transaction IDs, which are numbers assigned to keep different transactions in order. Conveniently, the first sixteen bits of a DNS packet is just such a unique identifier. Itâ(TM)s called a query id (QID). And with the efficiency of the deli, the QID is used for multiple transactions.
2.

Until very recently, there were two basic classes of DNS vulnerabilities. One of them involves mucking about with the QID in DNS packets and the other requires you to know the Deep Magic.

First, QIDs.

Bobâ(TM)s a resolver and Alice is a content DNS server. Bob asks Alice for the address of WWW.VICTIM.COM. The answer is 1.2.3.4. Mallory would like the answer to be 6.6.6.0.

It is a (now not) secret shame of mine that for a great deal of my career, creating and sending packets was, to me, Deep Magic. Then it became part of my job, and I learned that it is surprisingly trivial. So put aside the idea that forging IP packets is the hard part of poisoning DNS. If Iâ(TM)m Mallory and Iâ(TM)m attacking Bob, how can he distinguish my packets from Aliceâ(TM)s? Because I canâ(TM)t see the QID in his request, and the QID in my response wonâ(TM)t match. The QID is the only thing protecting the DNS from Mallory (me).

QID attacks began in the olden days, when BIND simply incremented the QID with every query response. If you can remember 1995, hereâ(TM)s a workable DNS attack. Think fast: 9372 + 1. Did you get 9372, or even miss and get 9373? You win, Alice loses. Mallory sends a constant stream of DNS responses for WWW.VICTIM.COM. All are quietly discarded â"- until Mallory gets Bob to query for WWW.VICTIM.COM. If Malloryâ(TM)s response gets to your computer before the legitimate response arrives from your ISPâ(TM)s name server, you will be redirected where Mallory tells you youâ(TM)re going.

Obvious fix: you want the QID be randomly generated. Now Alice and Mallory are in a race. Alice sees Bobâ(TM)s request and knows the QID. Mallory has to guess it. The first one to land a packet with the correct QID wins. Randomized QIDs give Alice a big advantage in this race.

But thereâ(TM)s a bunch more problems here:

*

If you convince Bob to ask Alice the same question 1000 times all at once, and Bob uses a different QID for each packet, you made the race 1000 times easier for Mallory to win.
*

If Bob uses a crappy random number generator, Mallory can get Bob to ask for names she controls, like WWW.EVIL.COM, and watch how the QIDs bounce around; eventually, sheâ(TM)ll break the RNG and be able to predict its outputs.
*

16 bits just isnâ(TM)t big enough to provide real security at the traffi

Signatures

[DragonHawk]

Also anoying: people who don't use the signature facility and instead sign their messages manually so that others have no choice but to read them.

That's not a signature, it's a referral to evidence supporting my argument.

Re:Signatures

[Zebedeu]

Ops. Sorry, my bad :-)

DNS n00b

[Sir_Real]

So, I have a feeling like most people, I've heard of DNS, I know mostly what it does, but have no idea via what mechanism it does it. Could someone explain how bad this is? Normally, I treat claims like "DNS is broken" as being sensationalist. So far, slashdot seems to resolve. :) Should I be worried as a client that my queries are being answered by non-authoritative and possibly malicious servers? Can I drop another set of IPs into my /etc/resolv.conf and not have to worry?

Help me slashdot! You're my only hope.

I may be boned.

RPF Is...

[bill_mcgonigle]

That said, not an awful lot of people even have RPF deployed. Certainly nowhere near 100%. And it only takes one (or a handful of machines) that can forge UDP source addresses for this to be an issue.

Since those who don't have it deployed might not know what it is, some linkage to get them started.

Re:RPF Is...

[Michael Hunt]

Love where you're going with your website. Didn't think there were too many other people out there irate with Clinton for killing off EBR2/Clinch River. You just made my friends list.

Re:RPF Is...

[bill_mcgonigle]

Didn't think there were too many other people out there irate with Clinton for killing off EBR2/Clinch River.

Why, just because Clinton, Gore, and Kerry torpedoed our national and energy security for the sake of political appeal to whacko 'environmentalists'? That we might have been pulling out of the energy supply nosedive just about now? Why would that make anybody irate?

Re:RPF Is...

[Michael Hunt]

My understanding is that it was more about assaying fears of a so-called 'plutonium economy', never mind the fact that attempting to get any sort of weapons-grade plutonium out of IFR fuel would almost certainly kill you before you managed to do so.

It was a piece of political expediency at a time when nuclear energy was being demonized for two main reasons (fear of loss-of-coolant and fear of long-lived actinides). The stupid thing, of course, is that the IFR and its ilk are the only nukes that SOLVE that problem, and people are out there now talking about building more PWRs and BWRs to 'fix global warming.'

I suppose as long as someone, somewhere decides to revisit the closed-fuel-cycle fast reactor concept, we don't have too many worries in terms of the waste (because SOMEONE'll use it for fuel long before its 20,000-odd years are up.) The concern, of course, is doing that before it all gets dumped under some mountain somewhere and forgotten about forever.

Re:RPF Is...

[bill_mcgonigle]

The stupid thing, of course, is that the IFR and its ilk are the only nukes that SOLVE that problem, and people are out there now talking about building more PWRs and BWRs to 'fix global warming.'

Exactly, so I believe what you cited was the excuse, not the reason (this was like canceling anti-aging research because cancer is terrible). The other possibilites were astonishing ignorance or stupidity. I know the latter isn't true, and I suspect the former isn't either, though proof to the contrary could conceivably arise.

I suppose as long as someone, somewhere decides to revisit the closed-fuel-cycle fast reactor concept, we don't have too many worries in terms of the waste (because SOMEONE'll use it for fuel long before its 20,000-odd years are up.) The concern, of course, is doing that before it all gets dumped under some mountain somewhere and forgotten about forever.

Or dumped under a mountain and forgotten until the next civilization says, "hey, what's this? oooh, pretty."

Attack testing utility

[the_olo]

So did anyone write a tool to quickly test a DNS server for this vulnerability?

I mean, by actually performing the attack, with sending random queries and flooding it with forged replies until it gives us a poisoned result?

I'd like to, ehhh, test my servers whether I've got them properly patched. Yup, test my servers, that's all.

Mixing recursive resolvers with authoritative srvs

[the_olo]

If I understand the attack correctly, this time (against best practices) it would actually be beneficial to have the caching recursive resolver and an authoritative nameserver for your company's zones on the same machine, right?

Because this way at least the attacker couldn't fake the answers for company's zones to company's internal clients, because those answers wouldn't be cached, only served directly from zone files. The chance of successful attack is on those zones gets back to being defined by the QID and source port randomization of the client's stub - which is quite low. Am I correct?

Fixing DNS protocol vulnerability on linux system.

[Swordfish]

I've been writing up how I've been fixing the DNS vulnerability for 7 long nights after the announcement of the DNS vulnerability.

You might find my notes useful.

http://www.topology.org/linux/bind_bigbug.html

Rewrites, BIND 8 vs 9, and thanks

[DragonHawk]

Completely rewriting your code base is generally considered bad.

It is certainly bad if a rewrite is considered necessarily. That either means the code was so poorly written/maintained that it has become an unsalvageable mess, or that programmer understanding is so bad that a rewrite is needed just to grok things. Either way, it is basically a worst-case situation for the code base. But if that situation really has come to pass, then the fact that it's bad doesn't change the fact that it *is*. Kind of like major surgery; nobody really *wants* to have to have it, but if that's what's needed to fix a problem, better to do it.

I can't really speak to whether the BIND 8 rewrite was warranted or not. I saw some of the BIND 8 code back in the day, and it certainly seemed confusing, but I didn't take the time to understand it, so that might have been me. (I have the same reaction looking at the djbdns code.) The fact that BIND 9 has such a better track record when it comes to exploitable code bugs is suggestive, but not conclusive.

I can say that many of the exploitable bugs in BIND 8 appear to be fairly unremarkable code bugs (buffer overflows and the like). Best practices like chroot and least-privilege will help mitigate such -- keeping them from compromising the rest of the system -- but they won't eliminate them. If you're running a production nameserver, even a simple crash is a big problem. So I can't agree that the counter-measures you suggest would have been effective for BIND 8.

As for the rest of what you've posted... it's prolly best if we just agree to disagree. I doubt either of us is much interested in debating those issues with each other.

Thanks for taking the time to reply.

Google cache has cached it :)

[victorhora]

http://64.233.169.104/search?q=cache:vLwnQT2-RMIJ:www.matasano.com/log/1103/reliable-dns-forgery-in-2008-kaminskys-discovery/+matasano+%22reliable+DNS+forgery+in+2008%22&hl=pt-BR&ct=clnk&cd=1&gl=uk

information leaked?

[Anonymous Coward]

please read the source code of bind9 and the patch! u will understand it what the hell is going on! lol... FYI, attack tools already widely available :) it jz matter of time when they going to hijack u... :P

Re:Been seeing this for a while

[kayditty]

Not really. That's been around for a long time, and was pretty much solved once people stopped using RS.INTERNIC.NET for WHOIS. Unfortunately, the non-assimilated WHOIS we have to put up with for most of the gTLDs today sucks.

love LGBT

[Anonymous Coward]

As a member of LGBT, I always put my eyes on any issure about LGBT. This one is not an exception. I also talke aobut it with my biseuxal friends at http://Bimingle.com to know more details about it. Hopefully, more information can be published in time.