Large swaths of the internet remain at risk from a potentially crippling vulnerability in the net's address lookup system even after installing emergency patches, a researcher has warned. Russian researcher Evgeniy Polyakov posted exploit code here, which he says allowed him to poison domain-name system servers running the …

COMMENTS

House rules Send corrections

This topic is closed for new posts.

Monday 11th August 2008 22:11 GMT Tony Hoyle

10 hours?

Remind me not to let a guy with a russian accent attach a gigabit cable to my nameserver for 10 hours.

In that 10 hours he'd have to saturate the link... *someone* would notice and shut him down long before that. It's a very difficult attack to make outside the local LAN - ISPs routinely filter the source addresses of packets to stop exactly this kind of shenanigans, and have done for years.. not to mention getting gigabit bandwidth over a WAN requires the kind of access to hardware that most people simply don't have access to.

*any* protocol is vulnerable to brute forcing on that scale - it's not a vulnerability even more than my house is 'vulnerable' because someone with a tank could drive through the front to get in. Hell, by brute forcing NAT/State replies you could gain access to machines behind the firewall easily enough. Why stop at the nameserver?

OTOH just ARP spoof. Simpler, much easier and can be done in minutes on a 10mb LAN let alone a gigabit. This is why physical security is the #1 layer and always will be. If someone can plug into your LAN you're hosed.

0 0
Monday 11th August 2008 22:48 GMT Anonymous Coward

10 Hours is an average

But it could happen on the first try or within the first few seconds of trying. A better solution needs to be found - which is why I'm going through the DNSSEC documentation and tools right now.

0 0
Monday 11th August 2008 23:33 GMT Anonymous Coward

@Tony Hoyle

"ISPs routinely filter the source addresses of packets to stop exactly this kind of shenanigans, and have done for years.."

Your faith in ISPs is ... touching.

0 0
Tuesday 12th August 2008 00:32 GMT fronty

DNSSEC opens another an of worms

People say that DNSSEC is the answer but it's too unwieldy. Have you seen the size of the response packets? You could use DNSSEC to invoke a DNS amplification attack and DDoS your target with a mass of DNSSEC replies. I'm not sure it is the complete answer, we almost need to have a completely new way of achieving DNS type functionality, but without using the DNS protocol.

0 0
Tuesday 12th August 2008 09:03 GMT Anonymous Coward

Hmmmph

The bug, still at large in some places, means someone could steal my Register Comments log in credentials and post comments as me. What if they already had? What if this isn't actually me posting?

What's that? It's an improvement? Well, no need to sound so happy about it!

Hmmmph! No ... no need to hand me my coat - I'll leave of my own accord, thankyou very much.

0 0
Tuesday 12th August 2008 09:03 GMT Anonymous Coward

@ fronty

"we almost need to have a completely new way of achieving DNS type functionality, but without using the DNS protocol."

IPV6 combined with SSL certificates that are based on 164 bit encryption should do the job nicely.

Mine is the silver herring bone tweed one with the shimmering brown patches on the elbows and the hexadecimal calculator in the left side pocket, thanks.

0 0
Tuesday 12th August 2008 09:03 GMT Anonymous Coward

Easy fix: replace BIND with DJBDNS

"Forging a real fix won't be easy"

A real fix is as easy as installing DJBDNS instead of BIND. There has never been any vulnerability discovered in DJBDNS and it certainly is not vulnerable to cache poisoning. It's lightweight, too. No DNSSEC needed.

0 0
Tuesday 12th August 2008 09:03 GMT Eugene Crosser

@Tony Hoyle & @AC

>> "ISPs routinely filter the source addresses of packets to stop

>> exactly this kind of shenanigans, and have done for years.."

> Your faith in ISPs is ... touching.

Source address filtering does not work against DNS poisoning attack, as the forged packets have the source address of the real DNS server.

On a related note, Polyakov's attack (practically) cannot be mounted against ISP servers, due to bandwidth constraints. But, it *can* be mounted against a corporate network by means of trojaned system(s) on the LAN. OTOH, in the latter case, the attack can be stopped by packet filtering.

Eugene

0 0
Tuesday 12th August 2008 09:03 GMT Chris Campbell

Re:10 Hours is an average

We don't know how many times he succeeded with this tactic, so accepting 10 hours as an average isn't really a good idea. It's like rolling a dice once, getting a 6 and calling that the average roll of a dice.

Also, it goes both ways, it's theoretically possible to get it first try and succeed instantly, but it's also possible to go on for much much longer than 10 hours.

0 0
Tuesday 12th August 2008 09:03 GMT Steve

completely new way of achieving DNS type functionality,

> but without using the DNS protocol.

NIS/YP?

LDAP?

0 0
Tuesday 12th August 2008 09:03 GMT Anonymous Coward

New plan!!

Why don't we all just use HOSTS files? :)

0 0
Tuesday 12th August 2008 09:28 GMT Anonymous Coward

Re: Easy fix: replace BIND with DJBDNS

Just read:

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

and it DOESN'T prevent this attack. The comment about cache poisoning there refers to a completely different (and braindead) attack method.

So can you point to something that shows it cannot be poisoned using the method here, and 10 hours over a gigabit link? :)

0 0
Tuesday 12th August 2008 11:04 GMT David Cornes

Critical?

I decided I need to check up on MS patches for this little baby last week. MS08-037 seems to be the one that covers this "gaping hole that bring an end to all of online civilisation" I believe.

So why isn't this offered or even LISTED on Windows Update, for either my XP clients or 2003 server (which runs in-house DNS)??

0 0
Tuesday 12th August 2008 11:04 GMT JPQ

RE: Easy fix: replace BIND with DJBDNS

Isn't the problem with how the protocol itself works?

0 0
Tuesday 12th August 2008 11:04 GMT JPQ

RE: DNSSEC opens another an of worms

The client side could wait for a response from two servers and compare them? Not perfect, but it could help.

0 0
Tuesday 12th August 2008 11:21 GMT Tony Hoyle

Source address filtering does work

Source address filtering works against any spoofing attack. The packets never leave the source network (most routers actually do this by default - linux has it built in to filter them.. calls them 'martian packets' and drops them.. cisco routers just drop them silently... no need to rely on the competence of the ISP).

That limits the attack to the local LAN - and once you're on that then the number of attack vectors is so large you'd be insane to attempt to brute force a DNS server - there are *much* easier ways to screw things up and they don't take 10 hours or even 1 hour.

As mentioned this not unique to DNS - any protocol that wants a reply can be spoofed given that kind of access and enough time (and for things like zeroconf and upnp 'enough time' is about 1/10th of a second). It's not fixable because the problem isn't with the protocol it's with allowing someone access to your LAN without adequate security.

0 0
Tuesday 12th August 2008 11:42 GMT Anonymous Coward

TCP

Another option would be to rework DNS to use TCP rather than UDP.

0 0
Tuesday 12th August 2008 23:26 GMT Anonymous Coward

Or add a slow-down to reduce the risks further

Insert a Load Balancer, and ensure round-robin is used on the farm or caches. Now its incredibly difficult to doing poisoning. Go to Starbucks.

0 0
Tuesday 12th August 2008 23:26 GMT Anomalous Cowherd

Protocol is the issue

You've got a 16-bit transaction ID and (with DJBDNS and now, with BIND) a 16-bit port. That's 32 bits of entropy now, which is why it's taking 10 hours over a fast line on average now, rather than the few seconds required for 16 bit of entropy provided by just the ID.

There's no more entropy to squeeze out of the existing protocol, so if 32-bits isn't enough and you don't fancy DNSSEC how about modding your caching nameserver to make each request twice and compare both results to ensure they're the same?That's 64-bits of entropy, and I imagine it's an easier upgrade path than DNSSEC - a few extra packets isn't as much of an issue as it was 10 years ago.

0 0
Wednesday 13th August 2008 16:17 GMT Anonymous Coward

@TCP

"Another option would be to rework DNS to use TCP rather than UDP."

That would make DNS really suck. No thanks. Besides, if you are going to change the lower layer protocol, why not use something that's more reliable and faster: SCTP.

0 0