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!

Massive, Coordinated Patch To the DNS Released

kdawson posted more than 6 years ago | from the pretty-much-everybody dept.

Security 315

tkrabec alerts us to a CERT advisory announcing a massive, multi-vendor DNS patch released today. Early this year, researcher Dan Kaminsky discovered a basic flaw in the DNS that could allow attackers easily to compromise any name server; it also affects clients. Kaminsky has been working in secret with a large group of vendors on a coordinated patch. Eighty-one vendors are listed in the CERT advisory (DOC). Here is the executive overview (PDF) to the CERT advisory — text reproduced at the link above. There's a podcast interview with Dan Kaminsky too. His site has a DNS checker tool on the top page. "The issue is extremely serious, and all name servers should be patched as soon as possible. Updates are also being released for a variety of other platforms since this is a problem with the DNS protocol itself, not a specific implementation. The good news is this is a really strange situation where the fix does not [immediately] reveal the vulnerability and reverse engineering isn't directly possible."

cancel ×

315 comments

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

Frosty P!ss (-1, Offtopic)

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

Wewt

So give a layman explanation (-1)

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

tkrabec alerts us to a CERT advisory announcing a massive, multi-vendor DNS patch released today. Early this year, researcher Dan Kaminsky discovered a basic flaw in the DNS that could allow attackers easily to compromise any name server; it also affects clients.

My mouth is full of sand and I don't understand.

Re:So give a layman explanation (3, Insightful)

X0563511 (793323) | more than 6 years ago | (#24104415)

Dan Kaminsky discovered a basic flaw in the DNS that could allow attackers easily to compromise any name server; it also affects clients.

If you don't understand that, you don't need to care.

Re:So give a layman explanation (3, Funny)

smitty_one_each (243267) | more than 6 years ago | (#24105055)

Recommendation is more CERTS, as they will help with the sand breath.

Oh cool! (4, Funny)

RockMFR (1022315) | more than 6 years ago | (#24104409)

http://www.doxpara.com/ [doxpara.com]

Your name server, at 65.24.7.3, appears vulnerable to DNS Cache Poisoning.

Sweet!

Re:Oh cool! (5, Funny)

brunascle (994197) | more than 6 years ago | (#24104489)

http://www.doxpara.com/

Your name server, at 65.24.7.3, appears vulnerable to DNS Cache Poisoning.

In fact, we arent even www.doxpara.com, we just hacked your name server. That's how we know.

Re:Oh cool! (1, Offtopic)

Archangel Michael (180766) | more than 6 years ago | (#24104575)

Not only that, its been slashdotted.

Re:Oh cool! (1)

mmyrfield (1157811) | more than 6 years ago | (#24104927)

"Error establishing a database connection" Does that mean my DNS is poisoned, or their server is slashdotted? =P

Re:Oh cool! (5, Insightful)

GeffDE (712146) | more than 6 years ago | (#24105581)

Seriously, is an IP address too much to ask?

Article should be modded +1 Ironic because the links necessitate the use of DNS...at the very least, the DNS checker should have been a straight IP.

WTF?

Re:Oh cool! (1)

mpathetiq (726625) | more than 6 years ago | (#24105087)

Oooh, that's the DNS server I use at home. Sweeeet.

Re:Oh cool! (1)

skeeto (1138903) | more than 6 years ago | (#24105247)

http://www.doxpara.com/ [doxpara.com]

stand by the wordpress it likes to have the cache

Uh... not vulnerable then?

More independent verification needed (3, Insightful)

suso (153703) | more than 6 years ago | (#24104425)

Here everyone, install this patch to your Unix/Linux DNS servers that was conceived of on the Microsoft campus.

While if true, one should be expedient to fix it, one should also be careful to verify that this is true.

Re:More independent verification needed (1)

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

Well, if you read the list, you'd know that Microsoft's own DNS implementation is also affected and in need of patching.

Re:More independent verification needed (3, Insightful)

suso (153703) | more than 6 years ago | (#24104579)

Well of course it is. Anyone can make a list. From the investigating I'm doing right now, it does seem to be legit. But I just think its important to be careful. Don't just blindly patch what is probably the most critical service on your network.

Re:More independent verification needed (1)

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

But I just think its important to be careful. Don't just blindly patch what is probably the most critical service on your network.

No competent sysadmin does that, of course. As always, you need to independently verify the need for any patches that are recommended for installation on your network.

Re:More independent verification needed (4, Insightful)

Schraegstrichpunkt (931443) | more than 6 years ago | (#24105443)

Right... How many otherwise competent sysadmins do you know who can't C code? I've known plenty. Usually the good coders get jobs as coders, rather than as sysadmins.

Re:More independent verification needed (2, Funny)

Anpheus (908711) | more than 6 years ago | (#24104653)

If you're using a Linux DNS server that's open source, why don't you just read through the source code and find out what changed, I mean, psht, it's so easy?

Yes, I'm being sarcastic.

Re:More independent verification needed (2, Insightful)

cduffy (652) | more than 6 years ago | (#24104791)

If you're using a Linux DNS server that's open source, why don't you just read through the source code and find out what changed, I mean, psht, it's so easy?

Yes, I'm being sarcastic.

Why the sarcasm? If you're hiring sysadmins who aren't also system-level developers, you're not hiring people who can Do The Job Right.

Granted, it's not realistic to read through every patch from upstream... but if it's something you consider that critical and are that suspicious of, yes, your staff should have the relevant expertise in-house to read and evaluate what's going on.

Re:More independent verification needed (3, Insightful)

isorox (205688) | more than 6 years ago | (#24105181)

but if it's something you consider that critical and are that suspicious of, yes, your staff should have the relevant expertise in-house to read and evaluate what's going on.

Or have the ability to recognise they are out of their depth and be able to use resources from other departments (or even external suppliers)

Re:More independent verification needed (2, Insightful)

Darkness404 (1287218) | more than 6 years ago | (#24105197)

But how many companies really need sysadmins that are system-level developers? Now, granted, it is good to have a sysadmin who can write programs in binary and such, but most don't need that. They just need someone who knows how to put the HTML on the servers and make it work. They need someone who can bail out the boss who managed to forget his password, they need someone who can figure out if it is your monitor that is broken or your graphics card. But for most small-ish businesses (less then 100 employees), they just need/want someone who can set up a server and fix it when it breaks. Nothing more, nothing less.

Re:More independent verification needed (5, Funny)

es330td (964170) | more than 6 years ago | (#24105303)

it is good to have a sysadmin who can write programs in binary

I'd like to meet one of these sysadmins. I've written system stuff in C and other stuff in Pascal, C++ and Perl over the years but the guy that can write direct to binary must really know his stuff. Just think, his keyboard only needs two keys!

Re:More independent verification needed (2, Insightful)

cduffy (652) | more than 6 years ago | (#24105633)

Hey -- building or patching executables opcode-by-opcode is a time-honored tradition among crackers, old-school virus writers and masochists.

Granted, hex isn't *quite* binary...

Re:More independent verification needed (1)

nko321 (788903) | more than 6 years ago | (#24105219)

Honestly, how many people do you know who fit the bill you've described, and how did they capture that much expertise? And what kind of company are you working at, anyway? I've never worked for a company with more than 150 people and I doubt they could afford such a guru.

Re:More independent verification needed (4, Insightful)

Penguin Follower (576525) | more than 6 years ago | (#24105263)

So you are insinuating that all system admins also have to be programmers? There are plenty of people with the skills to set up, maintain, and secure (properly) systems of all kinds (*nix, Windows, Macs, Cisco equip) who are NOT programmers. Some people are not cut out to be programmers, but are quite capable outside of that realm...

Re:More independent verification needed (0)

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

So you are insinuating that all system admins also have to be programmers? There are plenty of people with the skills to set up, maintain, and secure (properly) systems of all kinds (*nix, Windows, Macs, Cisco equip) who are NOT programmers. Some people are not cut out to be programmers, but are quite capable outside of that realm...

True... But any decent Sysadmin better be able to program.

Sure, I wouldn't expect your Sysadmin to be coding up a replacement to Word or a cool new shooter... But they better be able to read code and bash together some scripts.

Re:More independent verification needed (5, Insightful)

lukas84 (912874) | more than 6 years ago | (#24105577)

Why the sarcasm? If you're hiring sysadmins who aren't also system-level developers, you're not hiring people who can Do The Job Right.

People with that amount of expertise will hardly be challenged by sysadmin position. And without a challenge you'll get bored. As such, you'll never find people with such high qualifications in sysadmin position.

A sysadmin of course needs to know his stuff, and especially a unix sysadmin should be able to read C code and get the basics (and have extensive knowledge in scripting languages).

But i doubt that understand the gritty details how bind works (or reading a DNS packet with just a hex editor) is something that can be expected from a sysadmin.

But i also might just be defending my lack of knowledge, so beware :)

Re:More independent verification needed (3, Funny)

InlawBiker (1124825) | more than 6 years ago | (#24104883)

It's easy, you just look for a comment like: /* BEGIN bug causing possible MASSIVE future EXPLOIT. */

Re:More independent verification needed (2, Funny)

74nova (737399) | more than 6 years ago | (#24104975)

It could also be near something like //fsck it, I'm going to lunch

Re:More independent verification needed (3, Funny)

Dan667 (564390) | more than 6 years ago | (#24105095)

If I was a hacker I would look for that comment to find an exploit in the first place. And other like

// this is ugly, but it seems to work
// remember to fix this later
// whoever wrote this sucks

Re:More independent verification needed (3, Funny)

lgw (121541) | more than 6 years ago | (#24105203)

Oh, the only one your *really* need to look for is // should never happen

although // drunk now, fix later

is also good.

Re:More independent verification needed (1)

lgw (121541) | more than 6 years ago | (#24105391)

Wow, when did slashcode mangle lines starting with //? More like "drunk now, fix never"!

Re:More independent verification needed (1)

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

Also:

// this [data||condition| is invalid.
// *** FIXME: Not sure how to handle this. ***

Re:More independent verification needed (1)

uncledrax (112438) | more than 6 years ago | (#24105357)

What? comment your code?

Ludicrous!!

And I don't mean the guy that dances and wears diamonds.

I imagine the open-source 'vendors' have discussion about the topic somewhere.. right?

Ridiculous. (0)

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

We only tolerate half-truths at Slashdot. Unless, of course, the truth coincides with what we believe. Then we're quite insistent on the whole truth thing.

Reading the article is, thus, a large gamble. I applaud suso for choosing wisely and avoiding the possibility of cognitive dissonance.

Re:More independent verification needed (5, Funny)

dvice_null (981029) | more than 6 years ago | (#24104701)

> Microsoft's own DNS implementation is also affected

Did anyone else notice that today is Tuesday?

Re:More independent verification needed (1)

joeytmann (664434) | more than 6 years ago | (#24105227)

good point.

Re:More independent verification needed (2, Interesting)

jeremypv (455256) | more than 6 years ago | (#24105283)

>Did anyone else notice that today is Tuesday?

http://www.microsoft.com/technet/security/bulletin/ms08-037.mspx

Re:More independent verification needed (2, Informative)

Nos. (179609) | more than 6 years ago | (#24104787)

Except your Unix/Linux server is probably using BIND , and ISC has released a patch (and lots more information): http://www.isc.org/index.pl?/sw/bind/bind-security.php [isc.org]

Re:More independent verification needed (1)

SpaceLifeForm (228190) | more than 6 years ago | (#24105111)

DNS administrators who operate these servers behind port-restricted firewalls are encouraged to review their firewall policies to allow this protocol-compliant behavior. Restricting the possible use of various UDP ports, for instance at the firewalls, in outgoing queries and the corresponding replies will result in decreased security for the DNS service.

So, I have to open up more UDP ports in the firewall.

I'm not sure I like this band-aid.

Re:More independent verification needed (3, Informative)

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

Do you really have your firewall restricted in such a way that UDP packets are only allowed through if they come from specific ports?

In other words, do you care if a query to an external DNS server comes from port 15875 or port 15876 on a machine in your behind-the-firewall network? Likewise, do you care if incoming DNS queries to your DNS server come from port 28410 or port 28411 on Comcast's DNS server?

Since it's currently random (but fixed at startup of the server) in some DNS implementations, this shouldn't affect anything for 99.99% of people. Any sysadmin who sets up firewall rules that were so stringent as to assume a source port for a protocol that doesn't require a specific source port should have to deal with the trouble their stupidity caused.

Re:More independent verification needed (1)

brouski (827510) | more than 6 years ago | (#24104819)

Are you seriously suggesting the possibility that this is a plot by Microsoft to somehow break or degrade Unix/Linux servers?

not that big of a problem (5, Informative)

simul (113898) | more than 6 years ago | (#24104459)

I used to run a DNS hosting company. Fortunately, this error only affects caching resolvers, since it is yet another example of cache poisoning. There have been (and continue to be) hundreds of cache poisoning exploits over the years. This one is fairly technical and would require significant expertise to execute in a timeframe (ie: before everyone patches up) to cause harm. I don't know about you,but if someone started flooding my servers with thousands of response regords in hopes of guessing a transaction ID, my iptables config would block them in a heartbeat.

this is not the kind of security problem that should cause people's heart to skip a beat. your average malware worm is much worse.

dan has written an article on a javascript attack that can compromise a home router [google.com] .... that's probably far worse - in terms of real damage (ie: bot creation, personal data stolen)

in sum... run yum update.... then don't worry about it.

Re:not that big of a problem (5, Interesting)

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

an has written an article on a javascript attack that can compromise a home router.... that's probably far worse - in terms of real damage (ie: bot creation, personal data stolen)

And that's precisely why the first thing I do on a home router is to disable the cashing nameserver and install DJBDNS on a Linux box instead. :)

Re:not that big of a problem (-1, Troll)

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

Moron. You buy a router with a caCHING nameserver then disable it to run some backwater voodoo from a net-kook. For this you were modded interesting?

Moderators asleep at the wheel today?

Re:not that big of a problem (1, Insightful)

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

"javascript attack that can compromise a home router"

From one of the articles:
"The technique, called a DNS rebinding attack, would work on virtually any device, including printers, that uses a default password..."

In other words, if you're stupid enough not to change your password, you're going to get your router hacked. No fucking shit, Sherlock.

Re:not that big of a problem (2, Interesting)

PCM2 (4486) | more than 6 years ago | (#24105009)

Am I right in guessing that the Web page containing the payload would have to be coded with the default password AND the default IP address of your router's admin interface? I'm sure I'm in the minority, but I generally set my subnet to a 10.x.x.x address block when I first configure my home router.

Re:not that big of a problem (1)

CastrTroy (595695) | more than 6 years ago | (#24105143)

Well, the default config should make it so that if you do absolutely nothing, then you are safe. The default password should be set to the serial number already printed on the bottom of the router. Or something else that is sufficiently hard to guess.

Re:not that big of a problem (2, Funny)

negRo_slim (636783) | more than 6 years ago | (#24105201)

In other words, if you're stupid enough not to change your password, you're going to get your router hacked. No fucking shit, Sherlock.

Ahhh the joys of default passwords. I remember my high school's implementation of network security which had a few default passwords just waiting be found via lycos... or was it hotbot back then?

Either way when it was discovered I was assuming control of my work station to increase screen resolution to effectively use the IDE they had provided, well they slapped me on the wrist and brought me back down to 640x480 for security reasons of course. When I said fuck it and wrote a program that changed the resolution for me with the skills I had been taught in that class... Oddly enough instead of a passing grade my school year dramatically shortened. ie Explusion.

Stupidity and default passwords ftw!

Re:not that big of a problem (1)

Bert64 (520050) | more than 6 years ago | (#24105499)

I got in trouble at school for using keyboard shortcuts instead of going through the menus... Many of the people teaching these classes have no idea and just blindly follow a textbook..
Our school sysadmin was the unemployed husband of the school librarian, and needed a job.

Re:not that big of a problem (1)

Schraegstrichpunkt (931443) | more than 6 years ago | (#24105531)

Either way when it was discovered I was assuming control of my work station to increase screen resolution to effectively use the IDE they had provided, well they slapped me on the wrist and brought me back down to 640x480 for security reasons of course. When I said fuck it and wrote a program that changed the resolution for me with the skills I had been taught in that class... Oddly enough instead of a passing grade my school year dramatically shortened. ie Explusion.

Yeah, I saw that start to happen at my school. I was one of the last people who got away with that sort of thing before everyone went OMG-psycho. Luckily, I graduated before it got too bad.

Re:not that big of a problem (0)

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

"yum update"? LOL, nobody uses RedHat based distros any more you dork.

Re:not that big of a problem (2, Insightful)

Hyppy (74366) | more than 6 years ago | (#24105145)

Except for a large number of businesses that are of sufficient size to run DNS services, and which demand some level of support with their mission critical operating systems.

Re:not that big of a problem (1)

Matt Perry (793115) | more than 6 years ago | (#24105103)

if someone started flooding my servers with thousands of response regords in hopes of guessing a transaction ID, my iptables config would block them in a heartbeat.

Would you be kind enough to publish your iptables config that does that? Such a set of rules seems like it would be very useful.

Re:not that big of a problem (0)

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

Too bad you don't actually know what the exploit is... I love people that talk through their hind-portions.

Any name server? (1)

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

I don't see djbdns listed... except in the references and credits.

Re:Any name server? (0)

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

It's a problem with the resolver, not the server, apparently.

Re:Any name server? (2, Informative)

Russ Nelson (33911) | more than 6 years ago | (#24105399)

djbdns consists of a separate server (tinydns) and resolver (dnscache).

Hmmm (1)

Achromatic1978 (916097) | more than 6 years ago | (#24104467)

The good news is this is a really strange situation where the fix does not immediate reveal the vulnerability and reverse engineering isn't directly possible.

So, uhh, why the secrecy in planning the fixes?

Re:Hmmm (4, Insightful)

outZider (165286) | more than 6 years ago | (#24104663)

Because it isn't 1912, and we aren't on the Titanic. They can say with reasonable confidence that it's difficult to find the underlying issue, but nothing is hackproof, or sinkproof, or lameproof.

DJBDNS not affected. (5, Informative)

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

Note that DJBDNS (and derivatives) are not affected, since it uses randmoized source ports for DNS resolving.

Let the DJBing begin! (3, Interesting)

swb (14022) | more than 6 years ago | (#24104831)

Attention all DJB software fans, here's another chance to champion the superiority of DJB's software. Don't forget to include positive commentary on the licensing and patch status.

Thanks!

Re:Let the DJBing begin! (0)

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

Yey! Qmail!

Re:Let the DJBing begin! (5, Funny)

Cyberax (705495) | more than 6 years ago | (#24105053)

Uhm...

DJB-ware is now in _public_ _domain_. That's even more liberal than the BSD license.

So, update your /etc/hate file with newer facts...

Re:Let the DJBing begin! (1)

Free the Cowards (1280296) | more than 6 years ago | (#24105367)

That's pretty hilarious. You realize that your comment is precisely the "positive commentary on the licensing" that he requests of you?

Re:Let the DJBing begin! (1)

Cyberax (705495) | more than 6 years ago | (#24105489)

Nope.

Until recently DJB-ware had a very, shall we say, peculiar license (i.e. no license at all). The grandparent was referring to this fact.

Re:DJBDNS not affected. (1)

timster (32400) | more than 6 years ago | (#24105027)

Now hold on. I read the article, and it didn't say what the vulnerability was. So your assertion that a particular technique would protect against this particular vulnerability must be based on knowledge of what the vulnerability entails, but the article is claiming that this is some big secret. Care to elaborate?

Re:DJBDNS not affected. (1)

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

FTFCA (From the flippin' CERT Advisory):

Because attacks against these vulnerabilities all revolve around the ability for the attacker to predictably spoof traffic, the implementation of per-query source port randomization in the server presents a practical mitigation against these attacks within the boundaries of the current protocol specification. Â

Re:DJBDNS not affected. (4, Funny)

Just Some Guy (3352) | more than 6 years ago | (#24105371)

Note that DJBDNS (and derivatives) are not affected, since it uses randmoized source ports for DNS resolving.

Also not affected: DJBDNS's IPv6 and IXFR functionality, since Dan didn't want to bother implementing them.

Re:DJBDNS not affected. (0, Flamebait)

bignetbuy (1105123) | more than 6 years ago | (#24105501)

Great! So the four people that actually use DJBDNS don't have to patch it. Thank you!

Sinisterness (2, Funny)

COMON$ (806135) | more than 6 years ago | (#24104485)

FTA The good news is this is a really strange situation where the fix does not immediate reveal the vulnerability and reverse engineering isn't directly possible.

FTA Update: Dan just released a "DNS Checker" on his site Doxpara.com to see if you are vulnerable to the issue.

in other news

Sooooooo, Im supposed to run a random file on my network to check an unknown DNS issue...this just reminds me all too much of those "download our program to fix all your antispyware issues" alerts.

And finally the obligatory profit usage:

1. Find a vulerability

2. Dont tell anyone what said vulnerability is.

3. Release malware in the form of a "Patch" to "Fix" the issue exploiting thousands of servers.

4. ???

5. PROFIT!

Re:Sinisterness (4, Funny)

StreetStealth (980200) | more than 6 years ago | (#24104581)

Still, it's not exactly like you clicked a banner with a lame attempt at a bouncing, fake window telling you your DNS software was in immediate need of a fix and that this combination patch and shopping buddy would fix it.

Re:Sinisterness (1)

InlawBiker (1124825) | more than 6 years ago | (#24104689)

Release malware in the form of a "Patch" to "Fix" the issue exploiting thousands of servers.

Well, you have to trust your vendor at some point right? Trust enables us to run yum or apt-get without having to read every line of source code for each upgraded package. I suppose having an open-source vendor is an advantage if you don't trust your supplier. But if you don't trust them why are you using them?

The fact that so many are doing this at once might be a clue that it's real.

Re:Sinisterness (1)

COMON$ (806135) | more than 6 years ago | (#24104751)

sure, but it only works with step 1,2 and the elusive 3, geesh. At least usually you get told what the patch is for.

Re:Sinisterness (1)

kormoc (122955) | more than 6 years ago | (#24105255)

At least usually you get told what the patch is for.

Why not take a gander at the vendor's site then?

Example:
bind - CERT VU#800113 DNS Cache Poisoning Issue [isc.org]

Just cause the author of the post says it's a 'vendor secret' doesn't mean the vendors think so...

I would say that this is a pretty serious issue... (2, Interesting)

iXiXi (659985) | more than 6 years ago | (#24104505)

"An attacker with the ability to conduct a successful cache poisoning attack can cause a nameserver's clients to contact the incorrect, and possibly malicious, hosts for particular services. Consequently, web traffic, email, and other important network data can be redirected to systems under the attacker's control." Too bad the fix doesn't 'Cure' the problem. It only makes it more difficult. "ISC is providing patches for BIND 9.3, 9.4 and 9.5" - Thank the Internet gods.

Re:I would say that this is a pretty serious issue (1)

postbigbang (761081) | more than 6 years ago | (#24104719)

Serious only if you're using BIND and a non-SOA DNS server. See http://secure64.com/products.shtml [secure64.com] for good reasons to ditch BIND if you have some spare $$.

Remember: no cache, no fooling around with cache for giggles.

A matter of time (2, Insightful)

courteaudotbiz (1191083) | more than 6 years ago | (#24104517)

This is utterly serious! And only a matter of time before attackers compromise DNS on servers and/or clients.

The good news is this is a really strange situation where the fix does not immediate reveal the vulnerability and reverse engineering isn't directly possible.

And wow! Great news! There's a very critical flaw over the entire Internet name-to-IP infrastructure. But don't bother, it will take time before the bad guys find what we fixed...

Reverse Engineering? (5, Informative)

ergo98 (9391) | more than 6 years ago | (#24104525)

From the summary-

The good news is this is a really strange situation where the fix does not immediate reveal the vulnerability and reverse engineering isn't directly possible

His DNS tester is submitting a DNS check that it knows will be relayed, and then monitoring if the upstream check (it is intentionally doing lookups against a DNS server it controls) consistently uses the same source port. If it does, hypothetically an attacker could send "response" packets in concert with the original request, poisoning the cache.

I would guess that the patch makes the DNS server randomize the nonce when relaying DNS requests.

I know nothing about this, but that's my super-l33t-hacker assumption from looking at it for 10 seconds.

Re:Reverse Engineering? (1)

Smidge207 (1278042) | more than 6 years ago | (#24104601)

Hans is that you?

=Smidge=

Oh noes, mah DNS! (1)

autophile (640621) | more than 6 years ago | (#24104621)

Error establishing a database connection

Finally...! (5, Funny)

JackassJedi (1263412) | more than 6 years ago | (#24104687)

I'm (sort of) a native German speaker, in which "DNA" is abbreviated "DNS" ("DesoxyribonukleinsÃure" with "sÃure" being "acid").
Needless to say, my first impression of the headline was way more futuristic than what is there.

Re:Finally...! (0, Funny)

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

With humour like that, I can see where the two world wars came from...

Re:Finally...! (1)

JackassJedi (1263412) | more than 6 years ago | (#24104907)

WTF it's not a joke? My initial thought before i read it again was that it was some kind of bioengineering feat...

Re:Finally...! (5, Funny)

Koiu Lpoi (632570) | more than 6 years ago | (#24105525)

"sÃure"

Welcome to the fail that is "no unicode on slashdot". Enjoy your stay.

CERT advisory in readable format: (3, Informative)

molo (94384) | more than 6 years ago | (#24104691)

Here is the CERT advisory in a readable format.

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

BTW, did they hold this for a Microsoft patch Tuesday?

-molo

Nature of the attack (5, Informative)

Animats (122034) | more than 6 years ago | (#24104739)

It's reasonably obvious from the CERT advisory how an attack would work. The CERT advisory tells us that the vulnerable systems are ones where the 16-bit DNS transaction ID and the 16-bit port number for a transaction are not randomly chosen. The CERT advisory also tells us that the attacker must be able to spoof IP addresses, that is, they must not be behind some ISP with egress filtering. CERT also tells us that it's a DNS poisoning attack.

So it looks like a form of this attack documented in 2003 [net-security.org] at "Cache Poisoning using DNS Transaction ID Prediction". Back in 2003, it took a large number of packets to make this attack work, and even then it wasn't reliable. But there may be a more cost-effective attack strategy if you know how the DNS server assigns transaction numbers and ports.

The fundamental problem comes from 1) the fact that source IP addresses can be forged, and 2) the DNS transaction ID, at 16 bits, is far too short to be considered a useful random key. Any key with security implications should be at least 64 bits and be generated by a crypto-grade random number generator.

Just in time for DefCon (1)

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

Good going Dan, this should add spice to the proceedings this year.

Great news for Debian users! (1, Insightful)

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

http://www.linuxcompatible.org/story115154.html

Oh joy!

Debian advisories.. glibc stub resolver effected! (5, Informative)

molo (94384) | more than 6 years ago | (#24104811)

Debian released 3 advisories:

bind9:
http://www.debian.org/security/2008/dsa-1603 [debian.org]

bind8:
http://www.debian.org/security/2008/dsa-1604 [debian.org]

glibc:
http://www.debian.org/security/2008/dsa-1605 [debian.org]

Bind9 now contains a port randomization, which can require firewall rule changes.

Bind8 is now considered deprecated and the advisory recommends upgrading to bind9. There is no patch for bind8.

The glibc stub resolver is also vulnerable, and there is no patch yet. The recommended workaround is to install bind9 as a caching resolver and point /etc/resolv.conf at localhost.

In short, this is a big mess.

-molo

The real solution... (4, Interesting)

Ethanol (176321) | more than 6 years ago | (#24104843)

...is to sign the root and deploy DNSSEC.

Unfortunately that's politically non-expedient. But now that this vulnerability is out there, maybe the political will can at last materialize.

The second-best solution is to deploy DNSSEC using DNSSEC Lookaside Validation [rfc-archive.org] (which means you get trust anchors from some other known site, not from the root zone). And that's available now.

The worst thing about DNSSEC is it's too damn complicated at present; there needs to be the equivalent of "one-click" zone signing. ISC (and others) are working on getting us closer to that.

The third-best solution is what's been done today. We just made it a lot harder to exploit the vulnerability--typically about 16000 times harder, depending on your configuration. There's a difference between "harder" and "impossible" though.

Lots of unkkon statuses... (1)

antifoidulus (807088) | more than 6 years ago | (#24104897)

Most of the companies in the list are "Status: unknown".....

Wait, HOW serious is this? (2, Insightful)

zero1101 (444838) | more than 6 years ago | (#24105065)

This is from the advisory.

Filter traffic at network perimeters
Because the ability to spoof IP addresses is necessary to conduct
these attacks, administrators should take care to filter spoofedaddresses at the network perimeter. IETF Request for Comments(RFC)
documents RFC 2827, RFC 3704, and RFC 3013 describe best currentpractices (BCPs) for implementing this defense. It is important to
understand your network's configuration and service requirements
before deciding what changes are appropriate.

So...is this REALLY that serious? Is anyone NOT already doing this? I'm incredibly skeptical of big, sensational security alerts like this.

djbdns apparently not affected (4, Informative)

Mr.Ned (79679) | more than 6 years ago | (#24105067)

... because djb recognized the vulnerability. it's even documented as such: http://cr.yp.to/djbdns/dns_random.html [cr.yp.to]

The nature of Reverse Engineering (1)

rindeee (530084) | more than 6 years ago | (#24105075)

I'd of thought that, by its very nature, reverse engineering is never really directly possible. Sorta why it has to be reverse engineered.

Irony of ironies (1)

Ch*mp (863455) | more than 6 years ago | (#24105085)

1. Subvert DNS so doxpara.com == (malware site)
2. replace "DNS checker tool" with rootkit.
3. ???
4. Profit!

My first response is to call Bullshit (-1, Troll)

BobMcD (601576) | more than 6 years ago | (#24105293)

I'm just distrustful, and I know that, but let's count the red flags on this one:

1) Un-named vulnerability

2) Un-disclosed patch content

3) DHS

4) All vendors working in concert

This is spooky as hell to me. Is it even possible for a single vulnerability to affect EVERY OS EVERYWHERE at once? That's uncanny, if it really is the case.

Re:My first response is to call Bullshit (3, Insightful)

winkydink (650484) | more than 6 years ago | (#24105559)

Google Dan Kaminsky and come back and talk.

Re:My first response is to call Bullshit (2, Funny)

Shados (741919) | more than 6 years ago | (#24105561)

Its a problem in the protocol. So the only systems that would not be vulnerable are those that did -not- follow the specs. Guess Windows is safe, since Microsoft never follows the specs :)

Re:My first response is to call Bullshit (1)

0racle (667029) | more than 6 years ago | (#24105645)

Is it even possible for a single vulnerability to affect EVERY OS EVERYWHERE at once?

No, but it is possible for a single vulnerability to affect every poor DNS implementation. From there you would be able to deploy OS specific attacks.

Bad summary including a Word document?? (2, Informative)

ockers (7928) | more than 6 years ago | (#24105529)

What a terrible summary. What would be really useful and news worthy would be a link to a web page with some information about the vulnerability. The links in the summary included: 1) a WORD DOCUMENT? WTF? 2) a PDF, 3) a podcast?? WTF? and 4) a link to a slashdotted DNS checker. How about a link to the CERT vulnerability web page which describes the problem?

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

Now THAT would have been much more useful. Do people who work as sysadmins actually have time to sit around listening to a podcast? Especially when there are DNS servers to patch?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?