Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Paul Vixie Responds To DNS Hole Skeptics

kdawson posted more than 6 years ago | from the be-afraid-be-very-afraid-then-get-patching dept.

The Internet 147

syncro writes "The recent massive, multi-vendor DNS patch advisory related to DNS cache poisoning vulnerability, discovered by Dan Kaminsky, has made headline news. However, the secretive preparation prior to the July 8th announcement and hype around a promised full disclosure of the flaw by Dan on August 7 at the Black Hat conference has generated a fair amount of backlash and skepticism among hackers and the security research community. In a post on CircleID, Paul Vixie offers his usual straightforward response to these allegations. The conclusion: 'Please do the following. First, take the advisory seriously — we're not just a bunch of n00b alarmists, if we tell you your DNS house is on fire, and we hand you a fire hose, take it. Second, take Secure DNS seriously, even though there are intractable problems in its business and governance model — deploy it locally and push on your vendors for the tools and services you need. Third, stop complaining, we've all got a lot of work to do by August 7 and it's a little silly to spend any time arguing when we need to be patching.'"

cancel ×

147 comments

Sorry! There are no comments related to the filter you selected.

I'm not worried (5, Funny)

niceone (992278) | more than 6 years ago | (#24194091)

I just remember the IP addresses and type them in myself. How hard is that?

Re:I'm not worried (4, Interesting)

socsoc (1116769) | more than 6 years ago | (#24194095)

That's really hard on web servers that host multiple domains on a single IP. Virtual hosting isn't exactly a new idea.

Re:I'm not worried (5, Funny)

Klaus_1250 (987230) | more than 6 years ago | (#24194155)

Why is that hard? Still works with IP-addresses. The only thing you need to do is to supply the Host-field as per HTTP/1.1.

Re:I'm not worried (4, Funny)

Lennie (16154) | more than 6 years ago | (#24197489)

That's why 'smart' people use /etc/hosts. That solves the problem of remembering and of the HTTP-host-header.

Re:I'm not worried (0)

Anonymous Coward | more than 6 years ago | (#24196667)

You just need to remember harder.

Re:I'm not worried (1)

element-o.p. (939033) | more than 6 years ago | (#24197389)

Not really:

$ telnet 209.112.170.79 80
Trying 209.112.170.79...
Connected to 209.112.170.79.
Escape character is '^]'.
GET http://www.element-o-p.com/ [element-o-p.com]
<...snip...>
$


Works just fine.

EDIT: Ignore the "[element-o-p.com]" in the snippet above -- /. is editing my post to make sure the URL in the GET line is unobfuscated -- even though it's not supposed to be a link (grrrr....)

Re:I'm not worried (1)

bill_mcgonigle (4333) | more than 6 years ago | (#24198841)

EDIT: Ignore the "[element-o-p.com]" in the snippet above -- /. is editing my post to make sure the URL in the GET line is unobfuscated -- even though it's not supposed to be a link (grrrr....)

You Preview? Welcome to the 1%.

Re:I'm not worried (1)

element-o.p. (939033) | more than 6 years ago | (#24202233)

Yeah, I like to be different :)

Re:I'm not worried (2, Insightful)

queldor (1184789) | more than 6 years ago | (#24194113)

Are you going to remember IP address in IPv6 also? Seems to me that DNS will become more important.

Re:I'm not worried (1)

Atti K. (1169503) | more than 6 years ago | (#24194167)

Damn, I forgot... what was slashdot again?

Re:I'm not worried (2, Informative)

Nullav (1053766) | more than 6 years ago | (#24194291)

216.34.181.48

Re:I'm not worried (3, Insightful)

Atti K. (1169503) | more than 6 years ago | (#24194609)

Where did you get thet? From a (unpatched!) DNS server maybe?

Re:I'm not worried (5, Funny)

Nullav (1053766) | more than 6 years ago | (#24194781)

Hey!
I am an unpatched DNS server, you insensitive clod!

Re:I'm not worried (0)

Anonymous Coward | more than 6 years ago | (#24195355)

whois record lookup and phone to sourceforge instead of typing nslookup
i do that for every website i visit. its secure.

Not so simple. (2, Interesting)

pleappleappleap (1182301) | more than 6 years ago | (#24196017)

Only if you have a method for authenticating the other side of the phone conversation.

Re:Not so simple. (1)

Lennie (16154) | more than 6 years ago | (#24197589)

And where you got the IP-address for the whois (hint it uses several hosts for different TLD/regions).

Re:Not so simple. (2, Funny)

skarphace (812333) | more than 6 years ago | (#24198471)

Only if you have a method for authenticating the other side of the phone conversation.

Visit the website and get the phone number, of course!

Re:I'm not worried (1)

pato101 (851725) | more than 6 years ago | (#24194207)

I just remember the IP addresses and type them in myself. How hard is that?

Gentlemen, We are reading a post from Chuck Norris [ebay.com] . Of course he is a "niceone", anyone willing to disagree?

Re:I'm not worried (4, Funny)

cnettel (836611) | more than 6 years ago | (#24194303)

I just remember the IP addresses and type them in myself. How hard is that?

That's all well and dandy until banner ads start flashing subliminal messages of unauthorized zone updates to you.

Re:I'm not worried (4, Funny)

Toutatis (652446) | more than 6 years ago | (#24194305)

How can you know then that the flaw isn't in your mind too.

Re:I'm not worried (2, Funny)

morgauo (1303341) | more than 6 years ago | (#24194421)

Meh! Just put the domains in your hostfile.... All of them....

Re:I'm not worried (0)

Anonymous Coward | more than 6 years ago | (#24198971)

I use hosts. Paul, come-in Paul.

BLACK DNS HOLE. Not just a security flaw. (-1, Troll)

Anonymous Coward | more than 6 years ago | (#24194097)

stability (2, Interesting)

eneville (745111) | more than 6 years ago | (#24194121)

ive never had to change tinydns installs for security reasons

Re:stability (2, Funny)

hostyle (773991) | more than 6 years ago | (#24194599)

I heard that this "security fix" is the addition of support for the Evil Bit [faqs.org] .

The back-biting is shameful (5, Insightful)

hal9000(jr) (316943) | more than 6 years ago | (#24194127)

this [informationweek.com] article at information week said it best the day after the announcement.

Geez, if you want responsible disclosure, you have to trust the experts when they say "it's new and it's bad"

Re:The back-biting is shameful (0)

Talsan (515546) | more than 6 years ago | (#24194189)

Haven't enough people been hurt by blindly trusting "experts"?* If there's one thing that everyone should have learned by now, if someone says "trust me", you should be skeptical.

This issue may be huge. But without all the necessary information, you can't make an informed decision as to whether or not you believe it is.

*This doesn't mean to imply that I don't think they're experts in their field.

Re:The back-biting is shameful (4, Funny)

wild_quinine (998562) | more than 6 years ago | (#24194259)

If there's one thing that everyone should have learned by now, if someone says "trust me", you should be skeptical.

No, you're off message. They need to click continue, because the screen has gone all dark and they can't get back to their web browser.

Re:The back-biting is shameful (4, Interesting)

tyler.willard (944724) | more than 6 years ago | (#24194279)

This issue may be huge. But without all the necessary information, you can't make an informed decision as to whether or not you believe it is.

That same information that allows you to make an "informed decision", as you so blithely put it, puts the integrity of the entire infrastructure and, more to the point, the information security of a whole lof of people at tremendous risk. Dammit, that's the whole point of the OP's observation and why people argue about disclosure in the first place.

Re:The back-biting is shameful (2, Insightful)

Talsan (515546) | more than 6 years ago | (#24194873)

That same information ... puts the integrity of the entire infrastructure and, more to the point, the information security of a whole lof of people at tremendous risk.

Extremist talk and dire predictions are great, but where have they gotten us in the past? Vixie claims that "Everything we thought we knew was wrong", but at the same time, we know that there are DNS systems and services that did not have this vulnerability, so obviously some people had already given this type of issue some thought.

I'm not saying don't patch. --Security holes should be fixed, after all. But if you tell people a house is on fire when there are no flames and no smoke, don't be surprised when people are skeptical.

Re:The back-biting is shameful (1)

tyler.willard (944724) | more than 6 years ago | (#24196191)

What does any of that have to do with the process or are you implying that disclosure policy is nothing to be concerned about?

Re:The back-biting is shameful (3, Interesting)

repvik (96666) | more than 6 years ago | (#24196559)

Vixie claims that "Everything we thought we knew was wrong", but at the same time, we know that there are DNS systems and services that did not have this vulnerability, so obviously some people had already given this type of issue some thought.

No. Not all dns systems/services may be vulnerable, but this might not be because of forethought but rather a different design paradigm (buzzword alert, I know). They might just have been designed differently for other reasons, and non-vulnerability to this exact flaw may be a side-effect.

Re:The back-biting is shameful (3, Informative)

Lennie (16154) | more than 6 years ago | (#24197671)

It was because of forethought of one man, DJB (Bernstein).

Re:The back-biting is shameful (0)

Anonymous Coward | more than 6 years ago | (#24199621)

I'm not saying don't patch. --Security holes should be fixed, after all. But if you tell people a house is on fire when there are no flames and no smoke, don't be surprised when people are skeptical.

That's straw-man argument. Nobody is saying anything comparable to "house is on fire", an example where the lack of fire/smoke would be obvious. This situation is more similar to a gas-leak warning.

Imagine being told that your coin boxes have a counterfeiting vulnerability that's higher risk than what one would normally expect and a weight-checking option should be added. You could do nothing just assuming that counterfeiting coins is too much effort to be likely. Then later word gets out that metal knock outs from electrical boxes installed at construction sites just happen to be the right size... next thing you know the kids all over town are collecting slugs...
(The potential loss in this example is low, and it is an example from long ago... and the size of the knock-outs has been changed and coin boxes now probably do check things like weight... and if modification is needed hardware is tougher to deal with than software, but hopefully you get the idea).

The potential damage from DNS-based hijacking is huge. The changes suggested make sense as far as they go and do not appear to offer any risk of introducing new vulnerabilities.
Can you cite any good reason NOT to act on the advice given????

Vixie claims that "Everything we thought we knew was wrong"...

Oh really. Looks like you made another straw man, and you use quotes as if he'd actually said that. I call B. S.

Re:The back-biting is shameful (1)

Kerkyon (584936) | more than 6 years ago | (#24202237)

Vixie claims that "Everything we thought we knew was wrong"...

Oh really. Looks like you made another straw man, and you use quotes as if he'd actually said that. I call B. S.

RTFA. He did actually say that. (Though I agree with most of what you said.)

Re:The back-biting is shameful (0)

Anonymous Coward | more than 6 years ago | (#24201363)

But if you tell people a house is on fire when there are no flames and no smoke, don't be surprised when people are skeptical.

I think the situation is more analogous to being told that "a potentially incendiary situation exists" when you have hay all over your floor, 5 gallon cans of paint thinner stacked all over the place (and a few of them are leaking) and a light fixture that periodically throws sparks.

Re:The back-biting is shameful (1)

Goaway (82658) | more than 6 years ago | (#24198397)

Haven't enough people been hurt by blindly trusting "experts"?

Do tell us what you think the ration of people saved to people hurt by blindly trusting experts is.

Re:The back-biting is shameful (1)

CrazedWalrus (901897) | more than 6 years ago | (#24202247)

Depends on whether their expertise extends beyond the word "expert" in front of their names.

The problem is that many people are introduced as experts that aren't really experts and don't have the background that the term implies. The modern media is great for implying expertise or authority on a given topic without there being any basis for it.

Example: Why interview Pat Robertson on economic issues? People who don't know who Pat Robertson is will assume he's an authority on the topic at hand. Otherwise, why would he be interviewed?

Re:The back-biting is shameful (1)

morgan_greywolf (835522) | more than 6 years ago | (#24194195)

Geez, if you want responsible disclosure, you have to trust the experts when they say "it's new and it's bad">

And that's one reason why I keep saying to hell with 'responsible disclosure'. But the more I say that the more people look at me like I'm some kind of space alien who just landed in a flying saucer.

Maybe then we wouldn't have software vendors taking weeks, months or years to patch remotely exploitable bugs (yes, I'm looking at YOU, Microsoft)

Re:The back-biting is shameful (4, Insightful)

tyler.willard (944724) | more than 6 years ago | (#24194329)

Maybe then we wouldn't have software vendors taking weeks, months or years to patch remotely exploitable bugs (yes, I'm looking at YOU, Microsoft)

Sure you would; and the blame for any damage would be blamed on who made the disclosure.

There is nothing wrong with how this was/is being handled. Limited disclosure with a solid and "reasonable" deadline is a perfectly fine way to balance the myriad issues with security threats.

Re:The back-biting is shameful (2, Insightful)

pfleming (683342) | more than 6 years ago | (#24195155)

Maybe then we wouldn't have software vendors taking weeks, months or years to patch remotely exploitable bugs (yes, I'm looking at YOU, Microsoft)

Sure you would; and the blame for any damage would be blamed on who made the disclosure.

There is nothing wrong with how this was/is being handled. Limited disclosure with a solid and "reasonable" deadline is a perfectly fine way to balance the myriad issues with security threats.

Except Microsoft doesn't handle things this way. If this had been only a Windows issue we would have never heard about it. The fact that Open Source is vulnerable as well means that we will eventually know what the problems were and be able to look to see that it was fixed in the Open Source versions.

Re:The back-biting is shameful (2, Insightful)

tyler.willard (944724) | more than 6 years ago | (#24196263)

This has nothing to do with any specific vendor or open source.

This issue is about how and when independent researchers disclose a vulnerability they find.

Re:The back-biting is shameful (1)

blincoln (592401) | more than 6 years ago | (#24196563)

The fact that Open Source is vulnerable as well means that we will eventually know what the problems were and be able to look to see that it was fixed in the Open Source versions.

Anyone with a serious interest in finding out the details of the flaw doesn't need the source code to figure it out, or to see what changes were made to address it. All they need are the binaries and a disassembler.

Re:The back-biting is shameful (3, Interesting)

Lennie (16154) | more than 6 years ago | (#24197709)

Not in this case, in this case seeing the source changes doesn't really help, it's more like a protocol-design-flaw. And the bugfix is just a workaround.

Re:The back-biting is shameful (1)

bill_mcgonigle (4333) | more than 6 years ago | (#24198803)

Maybe then we wouldn't have software vendors taking weeks, months or years to patch remotely exploitable bugs (yes, I'm looking at YOU, Microsoft)

Somebody benefits from the status quo.

Re:The back-biting is shameful (1)

morgan_greywolf (835522) | more than 6 years ago | (#24199193)

A wise man, you are.

Re:The back-biting is shameful (4, Insightful)

Goaway (82658) | more than 6 years ago | (#24194325)

So, you figure eighty vendors coordinated a simultaneous patch for some issue that is not really a big deal, probably just some guys vying for attention?

It's all a liberal plot (4, Funny)

spun (1352) | more than 6 years ago | (#24197491)

DNS cache poisoning is a myth cooked up by the liberal media and DNS scientists to implement their anti capitalist agenda.

And if it isn't a myth, then it certainly isn't man made, it's a natural phenomenon and there's nothing we can do about it.

ATTENTION MODERATORS: MOD PARENT DOWN (-1, Troll)

Anonymous Coward | more than 6 years ago | (#24197603)

The parent *needs* to be -1 Troll immediately.

Re:ATTENTION MODERATORS: MOD PARENT DOWN (3, Funny)

spun (1352) | more than 6 years ago | (#24197663)

Uh oh, somebody call the whaaaaambulance, we're going to need to perform a humor transplant here!

Re:ATTENTION MODERATORS: MOD PARENT DOWN (3, Funny)

Goaway (82658) | more than 6 years ago | (#24198387)

User ID 1352 trollin' it old skool!

Re:The back-biting is shameful (3, Insightful)

Anonymous Coward | more than 6 years ago | (#24194359)

Geez, if you want responsible disclosure, you have to trust the experts when they say "it's new and it's bad"

I don't want "irresponsible disclosure". I don't want to be vulnerable, while major corporations get to do marketing damage control. They had a hole. Ok, everyone makes mistakes. They found the hole. Great, then we can do something about it. Or not, because they kept quiet about it while secretly writing the fixes. They kept quiet about it for long enough that even Microsoft had fixes ready.

Meanwhile, peoples DNS servers have been exploitable. Yes, they were exploitable before that, but no good guys knew, and bad guys tend to keep information to themselves, so they can keep expanding their botnets.

But at least their image wasn't damaged by "you don't even have a patch yet? How many months is it going to take? (See Microsoft Internet Explorer)". The only victims were unsuspecting customers, who didn't turn the damn thing off (or at least replaced it with something like djbdns), because they weren't told that it was broken in the first place.

The "good guys" kept the information to themselves, until they had done their part. Just like the bad guys do. So where's the difference between the bad guys and the "good guys"?

Paul himself compared it with a house being on fire. If your neighbours house was on fire, would you be working in secret to fireproof the fence, and then tell your neighbour a few days later, "oh, btw, your house is on fire, started a couple of days ago. Here's a fire hose, see if anything can still be saved"?

They didn't take the hole seriously enough to warn us before "marketing damage control" was done. Why should we take it more seriously?

Re:The back-biting is shameful (0)

Anonymous Coward | more than 6 years ago | (#24194857)

Why should we take it more seriously?

Because the house is still on fire, whether you like their information policy or not.

Re:The back-biting is shameful (0)

Anonymous Coward | more than 6 years ago | (#24194951)

Right, but I have this messy and inconvenient halon fire suppression system. I don't want to use it, because it makes my life more difficult, but if the fire department can't make it for a few months, then maybe I'm going to use that system before the fire spreads to my wallet.

Yeah, that's it, stretch that fucking metaphor. Streeetch!

Re:The back-biting is shameful (0)

Anonymous Coward | more than 6 years ago | (#24196373)

When the so-called experts are in fact the parties responsible in the first place, then why the hell should we trust them? Of course, I don't want responsible disclosure. This is "real bad", and it has now been disclosed to probably a hundred random security and ops dweebs around the Internet. You going to trust every one of them? Let's see if it leaks before Blackhat....

A grown-up attitude from Vixie (0, Offtopic)

Kohath (38547) | more than 6 years ago | (#24194191)

If he posted that here, it would get modded Flamebait or Troll.

Doctors make the worst patients (5, Insightful)

wild_quinine (998562) | more than 6 years ago | (#24194233)

... and IT admins make the worst end users.

Knowing how to run a system is not purely technical knowledge, it's also a measure of professional ability. That means knowing when to take advice, and knowing who to take it from.

Also, prepare your botnets (0)

Anonymous Coward | more than 6 years ago | (#24194281)

You don't want to be lagging behind the competition. First on the unpatched box owns it.

Unfortunately, what else is new? (1)

geekmux (1040042) | more than 6 years ago | (#24194285)

Security expert discovers flaw

Tries to do the right thing and report it responsibly to vendors. Coordinates patch day responsibly.

People ignore it/blow it off/procrastinate and then proceed to throw blame and lawsuits against those who tried to help them in the first place.

They require a license to drive a car on a highway. Sure as hell would thin out the herd to require a license to drive a server on the information superhighway.

Re:Unfortunately, what else is new? (2, Interesting)

mrsbrisby (60242) | more than 6 years ago | (#24194367)

Not exactly.

This flaw was well known in 1990. Paul Vixie has been dragging his feet for almost twenty years with crack-potted shit like "additional credibility rules" and extra complexity.

How to fix this bug trivially was well known over ten years ago [cr.yp.to] and still the ISC has been refusing to secure its users because they want to push DNS-SEC- a security system based on a trust hierarchy that doesn't exist, whose implementation has never worked, and will never work because Paul is a fucking idiot who cares more about his own ego than just admitting he was wrong and learning to live with it.

Look even now:

Second, take Secure DNS seriously, even though there are intractable problems in its business and governance model

He can't help himself. He's a douchebag, and I hope he just leaves the Internet business forever. We'd all be much better for it.

Re:Unfortunately, what else is new? (5, Funny)

danFL-NERaves (302440) | more than 6 years ago | (#24194687)

Your mad ad hominem attack skills have convinced everyone that Paul Vixie is the know nothing douchebag in this conversation. Kudos!

Re:Unfortunately, what else is new? (3, Funny)

MadMidnightBomber (894759) | more than 6 years ago | (#24195387)

You broke my sarcasm meter.

Re:Unfortunately, what else is new? (1)

theskov (556173) | more than 6 years ago | (#24194881)

I don't really see where the trivial fix is, in the linked document. Are you talking about the fix that means renaming all domains to be too long to remember? How is that any better than using the raw IP-addresses?

Re:Unfortunately, what else is new? (1, Insightful)

Anonymous Coward | more than 6 years ago | (#24195163)

From reading the comments on the matasano blog [matasano.com] , I get a sneaky suspicion that the port randomisation is a mid-term workaround that they want everyone to get into place, before they reveal the actual hole (and fix, I hope). I don't think the port randomisation is the final fix...

The fact that he says (emphasis mine):

"So, as a temporary workaround, the affected vendors are recommending that Dan Bernstein's UDP port randomization technique be universally deployed."

makes me think so even more.

Re:Unfortunately, what else is new? (1)

Lennie (16154) | more than 6 years ago | (#24198161)

There is no real fix, other than changing than protocol in a backwards incompatible way. Port randomisation is a workaround and but it will give us some more years.

And that last part is just me guessing.

Re:Unfortunately, what else is new? (4, Informative)

gregmark (750089) | more than 6 years ago | (#24195283)

Randomizing UDP source ports does not solve the problem, it only makes it more difficult to impersonate the responding DNS server. Secure DNS makes this kind of impersonation impossible, or at least allows us to bask in the warm glow of impossible.

The DJB vs BIND thing is an illusion. Whatever everyone agrees is the best implementation should win and I doubt that Paul Vixie or anyone else at ISC thinks differently.

But it has become abundantly clear to me that DJB and his minions (of which I assume you are one) have failed to matter in most ways, not because of your ideas, but because of the brusque, immature manner in which those ideas are submitted for consideration, outside the standards committees which have served the Internet well for 30 years.

Re:Unfortunately, what else is new? (3, Interesting)

Znork (31774) | more than 6 years ago | (#24198545)

Secure DNS makes this kind of impersonation impossible

Mmm, no. It makes this kind of impersonation possible by anyone who can coerce/corrupt/control some part of the chain of trust.

outside the standards committees which have served the Internet well for 30 years.

Actually, on the topic of security and cryptography, I'd say the standards committees have failed the internet pretty badly. The apparent fixation with providing Verisign with revenue streams has gotten in the way of designing acceptable trust systems.

The only result that the fixation with certificates and authorities has gotten us is a situation wherein everyone is becoming their own authority and nobody cares about certificate warnings anymore.

If one wanted to repair the systematic damage by now, the best way would be to simply scrap the CA's out of browsers and anywhere else and just add a way to easily add specific CA's for each new domain/service provider one comes in contact with.

Re:Unfortunately, what else is new? (1)

nabsltd (1313397) | more than 6 years ago | (#24199561)

Secure DNS makes this kind of impersonation impossible

Mmm, no. It makes this kind of impersonation possible by anyone who can coerce/corrupt/control some part of the chain of trust.

I think a public/private key secured DNS would make it much harder to have this kind of impersonation work.

The biggest issue would be how would you securely get the public key for a particular domain. In other words, if Verisign (or somebody) signs the public key for example.com, then how do you get that signed public key so that when you get a signed DNS response from the example.com nameserver, you know it came from somebody who controls the private key for example.com.

The current SSL certificate infrastructure is pretty similar to what you would need, and it seems to work pretty well. There are ways to game it, and bad guys do get SSL certs, but overall it works.

But, a lot of the reason it works is because of the money. Most people that want SSL certs with a public CA want it because they are making money off that cert (Amazon, eBay, etc.). The vast majority of domains don't need SSL, but if secure DNS started rolling out, it wouldn't be long before you would be suspect if your domain didn't use it. Even at $10/year for current "no verify" SSL certificates, that would get to be pretty expensive "just for DNS". Probably the only way to really make it work would be for the DNS certificate to be included in the domain registration price.

What is Secure DNS (1)

maxinuruguay (1149501) | more than 6 years ago | (#24194319)

What is Secure DNS and where is the wikipedia article? Anybody?

Re:What is Secure DNS (5, Informative)

Anonymous Coward | more than 6 years ago | (#24194371)

"The Domain Name System Security Extensions (DNSSEC) are a suite of IETF specifications for securing certain kinds of information provided by the Domain Name System (DNS) as used on Internet Protocol (IP) networks. It is a set of extensions to DNS which provide to DNS clients (resolvers):

        * Origin authentication of DNS data.
        * Data integrity.
        * Authenticated denial of existence."

http://en.wikipedia.org/wiki/DNSSEC

Re:What is Secure DNS (3, Interesting)

_Knots (165356) | more than 6 years ago | (#24201595)

Unfortunately, as Vixie admits, DNSSEC has intractable problems and is... well, let's be generous and say "pushed too quickly through the standards process". (See http://cr.yp.to./djbdns/forgery.html [cr.yp.to] ; in particular, Vixie's observation 'We are still doing basic research on what kind of data model will work for dns security. After three or four times of saying "NOW we've got it, THIS TIME for sure" there's finally some humility in the picture... "wonder if THIS'll work?" ...' [this was _after_ several DNSSEC RFCs were approved and intended to be implemented were shown to be utter crap.])

Encouraging people to use DNSSEC is just about as useful as encouraging people to use HOSTS.TXT. OK, I exaggerate a bit, but it's simply not going to solve the problem, is going to expose zones to arbitrary enumeration (remember, The Internet community discouraged answering AXFR requests from the Internet at large presumably for a reason), and is going to introduce much larger computational demands of DNS servers that implement it.

(Here's a thought: most of this forgery comes from my ability to guess your DNS cache / resolver's query port and request ID. Come IPv6, we could surely add 48+ bits of entropy to the process by having DNS servers listen on a prefix of addresses. Much simpler, if gross.)

Re:What is Secure DNS (1, Informative)

Anonymous Coward | more than 6 years ago | (#24194379)

Secure DNS is a protocol which uses cryptographic signatures on DNS records to prevent DNS spoofing and other unauthorized manipulations. It has some problems which are mostly a result of DNS being a UDP protocol, which, for performance reasons, can't have long handshakes or cryptographic calculations on the server side.

YUO FAIL QIT (-1, Troll)

Anonymous Coward | more than 6 years ago | (#24194327)

Small business setups NOT protected by the patch? (1)

jkbull (453632) | more than 6 years ago | (#24194385)

From Paul Vixie's response: "Tom Cross of ISS-XForce correctly pointed out that if your recursive nameserver is behind most forms of NAT/PAT device, the patch won't do you any good since your port numbers will be rewritten on the way out, often using some pretty nonrandom looking substitute port numbers."

Does this mean that a typical small-business setup isn't protected by the patch?
 
For example, a server which provides recursive DNS and which connects to the Internet by a "cable" modem.

Oops! I meant cable router, not cable modem (1)

jkbull (453632) | more than 6 years ago | (#24194659)

Oops! I meant cable router, not cable modem

Re:Oops! I meant cable router, not cable modem (1)

larry bagina (561269) | more than 6 years ago | (#24195003)

It's a problem if your router uses NAT. Does your router use NAT? Is your DNS server behind the router?

Re:Small business setups NOT protected by the patc (1)

totally bogus dude (1040246) | more than 6 years ago | (#24194821)

It depends on how the NAT device assigns port numbers to outgoing queries. Apparently the fix for this flaw is to ensure the source port for lookups is truly random; some devices may use very predictable sequences (such as our Cisco ASA at work, mutter mutter).

If you visit Dan Kaminsky's blog [doxpara.com] , there's a DNS checker in the right hand panel which allegedly tells you if you need to worry or not. It just looks to see if all your queries for their test domain name came from the same port number.

Re:Small business setups NOT protected by the patc (2, Interesting)

socsoc (1116769) | more than 6 years ago | (#24194965)

Just another reason to make your local DNS forwarder use OpenDNS, or if you don't have one on your LAN, direct your router/workstations to OpenDNS. If your small-business LAN is relying on your provider's DNS, hopefully they patched it. Most worth their salt have, but OpenDNS also provides many features that are useful to small-business (in addition to not having been vulnerable to the flaw).

Re:Small business setups NOT protected by the patc (0)

Anonymous Coward | more than 6 years ago | (#24199401)

"Just another reason to make your local DNS forwarder use OpenDNS, or if you don't have one on your LAN, direct your router/workstations to OpenDNS. If your small-business LAN is relying on your provider's DNS, hopefully they patched it. Most worth their salt have, but OpenDNS also provides many features that are useful to small-business (in addition to not having been vulnerable to the flaw)." - by socsoc (1116769) on Tuesday July 15, @09:34AM (#24194965)

You may have to "watch it" though, with ActiveDirectory (AD) networks (or, possibly OTHER directory services too, that are heavily dependent on DNS services)... E.G.-> Using OpenDNS &/or ScrubIT DNS servers!

For example:

Using external DNS servers can "mess up" FULL Outlook's connections to Microsoft Exchange Servers on an internal ActiveDirectory network!

(I've seen it happen, & even listing another INTERNAL one as the "secondary DNS server" didn't seem to help on a job I was @ last year/earlier this year - @ least not w/ out using some "extra layered work-arounds" like VPN's & such)...

----

It makes sense they would make things on an AD LAN/WAN funny, for some things @ least, & email's pretty important as one that gets messed up:

I mean - How on earth could an external-to-your-LAN/WAN DNS Server know about your internal & probably NON-ROUTABLE IP Address servers (static types - 10.x.x.x/172.x.x.x) or even DCHP assigned addy ones (192.168.x.x etc.) & their IP assignments?

From what I have seen? Hey - A third party external DNS server, by default, will not & screws up Exchange to Outlook, on an AD Lan/Wan.

APK

P.S.=> If you guys can show me a workaround for this one, though I am NOT in those conditions anymore (AD lan/wan)? Let us know... thanks! apk

OpenDNS too slow and caused problems (last year) (0)

Anonymous Coward | more than 6 years ago | (#24199611)

I tried to use OpenDNS about a year ago. Ran on it for about 3 weeks. Some of the things were nice (typos on URLs getting fixed, for example), but the overall experience with them as primary DNS was pretty pathetic. OpenDNS response times were awful, taking as long as 3 to 5 seconds to resolve some pretty normal/standard FQDNs (i.e. www.google.com, mail.google.com, bank sites, etc.). At first I thought I something was up with my system, until I traced it back to resolv.conf pointing to OpenDNS. Set things back to real DNS and lo and behold, all my problems over the previous three weeks went away.

I checked them again earlier this year. Exact same problems. This time I only ran on them for a part of a day, as I recognized the problems they were creating immediately.

So, I won't use nor recommend OpenDNS for anyone any longer. Especially in homes or small offices where they have minimal infrastructure. If I had more space, equipment, etc. I might have considered deploying a caching name server for my systems, which might have alleviated some of the problems with OpenDNS, but that was too much work with too little gain.

Re:Small business setups NOT protected by the patc (1)

stderr_dk (902007) | more than 6 years ago | (#24200521)

Wouldn't that make it easier for an attacker to exploit your local DNS?
You just told him, that his fake DNS-responses should appear to come from either 208.67.222.222 or 208.67.220.220.

The truth comes out... (0, Troll)

slashname3 (739398) | more than 6 years ago | (#24194399)

Today at Black Hat the DNS exploit was explained and demonstrated in full. After getting 98% of the systems running DNS to apply an urgent patch it was disclosed that the patch was the hack. All patched DNS servers were then compromised during the Black Hat demonstration. This shows how a process can be used to introduce code that allows an outside entity full control of all systems on the network. During the demonstration Dan repeated his statement, "stop complaining, we've all got a lot of work to do by August 7 and it's a little silly to spend any time arguing when we need to be patching." Obviously he was refering to all the work he had to do to coordinate the largest take over of the Internet. A bot net of 100,000,000 systems was created in just a few minutes.

Re:The truth comes out... (1)

element-o.p. (939033) | more than 6 years ago | (#24201677)

Do you write plot themes for Hollywood?

The problem with conspiracy theories is that everyone involved in the conspiracy must keep silent, or else the conspiracy will be outed. Most people have a lot of trouble doing that because let's face it -- our egos are just too big. Unfortunately (or fortunately, depending upon whether or not you're in on the secret), once anyone else knows, everyone else knows.

So yeah, that sounds like it would be a great exploit, but do you really think it is likely that anyone could convince everyone involved to be a part of such a conspiracy? Surely *someone* would have refused, and to date, the only person I know of who is even loosely connected with FOSS that has...ummm...disappeared...lately is the late Mrs. Reiser.

But okay, let's assume you're right. So, Dan Kaminsky and Paul Vixie and everyone else involved manage to do what you described despite the problems I mentioned. Has everybody patched? Yeah, they created quite a scare, but sys admins are a skeptical, paranoid bunch. Surely someone left an unpatched system or kept the source code for the unpatched versions of the major DNS servers hidden away somewhere -- even if only the FOSS versions. So if on August 7th, everything goes to ****, a bunch of people roll back to the old version. Yeah, the world's largest beowulf cluster of bots is still running, but the really paranoid guys are busy rolling back to unpatched DNS servers, and are working on patches for all the compromised systems. Assuming that Kaminsky, Vixie and co. aren't bludgeoned to death by a mob of angry sys admins, how long do you think it will be until it's business as usual again?

So, are we all compiling from source all the time? (3, Insightful)

SlappyBastard (961143) | more than 6 years ago | (#24194471)

All paranoid theories about this issue sort of ignore the fact that unless you plan to install hundreds (or even thousands) of systems from your own compiled source for years and years to come, all of this discussion is at best academic.

The new distros are going to have the patch.

And really, considering the number of prehistoric vulnerabilities that should have been patched, that this one is finally getting patched is fine.

Yeah, there's a bit of "trust me" factor here with this patch, but a lot of good people are putting their credibility on the line for this patch.

All of this whole FOSS thing entails a lot of trust. I mean, you're really telling me that everyone on here whining about the need to see the source code has read every line of code in every OS they're using? There is a level at which we're all sort of hoping that the guys interested in each of the particular parts of the OS have done a thorough job in their separate efforts.

Re:So, are we all compiling from source all the ti (2, Insightful)

TubeSteak (669689) | more than 6 years ago | (#24196863)

All of this whole FOSS thing entails a lot of trust. I mean, you're really telling me that everyone on here whining about the need to see the source code has read every line of code in every OS they're using?

There's a specific phrase to describe it, but it escapes me at the moment.

Bascially, when you have a crowd of people standing around watching someone get beat up, nobody steps in to help, because everyone assumes someone else will help.

Verifying source code is somewhat like that: someone else will do it. The great thing about the internet is the crowd is so large that the few people, who would jump in no matter what, are always present.

Diffusion of Responsibility (3, Informative)

CrankyFool (680025) | more than 6 years ago | (#24198793)

You're looking for Diffusion of Responsibility [wikipedia.org] , made famous by the incident in which Kitty Genovese was murdered within earshot of a whole bunch of people, all of whom thought "damnit, someone should do something about this!"

Re:So, are we all compiling from source all the ti (1)

dave562 (969951) | more than 6 years ago | (#24200081)

Verifying source code is somewhat like that: someone else will do it. The great thing about the internet is the crowd is so large that the few people, who would jump in no matter what, are always present.

Of course they are. They stopped ignoring their mom shouting down into the basement that it was dinner time a LONG time ago. ;)

So its not the same flaw? (4, Informative)

BOFslime (178524) | more than 6 years ago | (#24195427)

I'm having trouble with Paul Vixies' line:

Q: "This is the same attack as described way back in ."
A: No, it's not.

When Dan Kaminsky states in his blog. [doxpara.com]

"DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use."
and
" 1) It's a bug in many platforms 2) It's the exact same bug in many platforms (design bugs, they are a pain) " How is this not the same flaw DJB described?

Re:So its not the same flaw? (4, Informative)

hal9000(jr) (316943) | more than 6 years ago | (#24195799)

1) It's a bug in many platforms 2) It's the exact same bug in many platforms (design bugs, they are a pain) " How is this not the same flaw DJB described?

You are looking at two separate issues. The flaw Kaminsky found is apparently a newly discovered design flaw that makes DNS forging easy even with todays, unpatched DNS servers. In the advisory, they discussed previous problems with generating the transactionID to explain the problem and point out that what Dan found is not something already known (alot of people missed that very obvious point).

The second seperate, issue is UDP source port randomization. That is what Kaminsky was referring to DJB's solution. Kaminsky's assertion is that UDP source port is a good development practice which DJB incorporated into his DNS server.

Bear in mind that UDP source port generation doesn't solve the underlying problem, it simply makes blind DNS forging more difficult because now an attacker has to guess both a pseudo random transaction ID and a pseudo random UDP source port number. Alot of DNS servers and OS, simply picked source port numbers incrementally or in the case of a DNS server, re-used the some one over and over.

I don't know hom much more difficult DNS forging will be by randomizing the UDP source port numbers. The additional keyspace is (2^16-1023) and you can probably divide that in half again. But it's better then nothing and probably provides enough time (the time it would take an attacker to blindly guess the transactionID and UDP source port number) for the actual response to hit the DNS server. In DNS, the first response wins.

Re:So its not the same flaw? (3, Informative)

xrayspx (13127) | more than 6 years ago | (#24196105)

DJB's source port randomization makes it much much harder to exploit the main bug, which is apparently a fundamental flaw in the DNS. We'll know on the 7th what that flaw is, but until DNSSEC or something similar is implemented, source port randomization will mitigate the risk until such time that the root cause is fixed.

Re:So its not the same flaw? (1)

Martin Spamer (244245) | more than 6 years ago | (#24197717)

Because a single flaw may be exploitable through multiple vectors of attack.

Though in this case source port randomization isn't the fix, it a stop gap that makes the flaw difficult to exploit in practice.

Re:So its not the same flaw? (1)

oneiros27 (46144) | more than 6 years ago | (#24200789)

Just because two problems have the same mitigation doesn't mean that they're the same problem.

You can take aspirin for a headache, or for a heart attack, but that doesn't mean that a headache is a heart attack or visa-versa. In some cases (I don't know the history, I never followed djbdns), you can have someone state a solution without a known attack -- 'This doesn't feel right, I don't think we should do it, but I can't say exactly why', and so we can get into a situation where there was no flaw for it to be the same as.

DJBDNS (0)

Anonymous Coward | more than 6 years ago | (#24195665)

I don't find the patches. Am I in a risk ?

So... (0, Flamebait)

bigstrat2003 (1058574) | more than 6 years ago | (#24195923)

Second, take Secure DNS seriously, even though there are intractable problems in its business and governance model -- deploy it locally and push on your vendors for the tools and services you need.

In other words, what he's saying is: "Take this new thing and deploy it, even though I admit it doesn't and can't work properly."

And this man doesn't see a problem with his logic? He must be certifiable.

CmdrTaco responds to goatse hole (-1, Troll)

Anonymous Coward | more than 6 years ago | (#24196277)

and by "responds" I mean "beats his meat like a rented mule."

Who is Paul Vixie? (0)

Anonymous Coward | more than 6 years ago | (#24196491)

I only take Bruce Schneier's word without peer review.

A simple test to run (4, Informative)

GeorgeK (642310) | more than 6 years ago | (#24197675)

In a comment to a question I posted for the CircleID article, Paul Vixie posted a nice and simple test that people can run to see how vulnerable they are:

dig porttest.dns-oarc.net in txt

FAIR or GOOD means you're ok, but POOR (which is the result I got) means you should be worried.

Re:A simple test to run (1)

brassman (112558) | more than 6 years ago | (#24200851)

Very confused here... I get "POOR" at home behind a NAT router; okay, I understand that. I run the same test on a remote server on the backbone, which is running the latest bind9, patched this week, and it gives exactly the same "POOR" result.

What hoop are we supposed to jump through to get a "GOOD" result?

Beware of ADSL router S-NAT on UDP ports. (1)

Swordfish (86310) | more than 6 years ago | (#24201983)

I did the "dig" test on my patched DNS servers, and one of them failed.
Reason: It was connected to an ADSL router by a 192.168.1.0/24 subnet which was translated by port S-NAT to a narrow range of source UDP ports.

As a result, all of the fixing of the DNS servers was made useless.
It was only the "dig porttest.dns-oarc.net in txt" test which exposed this.

Not that you should really do:

dig @your.dns.server porttest.dns-oarc.net in txt

where your.dns.server is the local DNS server behind your ADSL router or firewall which you want to test. Otherwise you don't really know _which_ server you are testing.

So I reconfigured my ADSL modem and that is okay now.

However...
On another site, the above "dig" test shows that everything is GOOD. But that is an illusion. What happened is that when the "dig" command is pointed with "@" at the local port of the ADSL router, the ADSL router's built-in DNS server uses the ISP's two DNS resolvers, and the _ISP's_ servers are patched. But the ADSL modem DNS requester is using fixed UDP source ports.

I can't find any definite confirmation of this. But I think this scenario is just as vulnerable as the worst case, even though the "dig" test says GOOD.

Cheers,
Alan.

Don't worry, Mr. Vixie (2, Funny)

93 Escort Wagon (326346) | more than 6 years ago | (#24199457)

Third, stop complaining, we've all got a lot of work to do by August 7 and it's a little silly to spend any time arguing when we need to be patching.

The patch is now in my crontab and set to run on the 6th.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?