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 most …
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.
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.
"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.
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.
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.
"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.
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.
@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.
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.
completely new way of achieving DNS type functionality,
> but without using the DNS protocol.
Why don't we all just use HOSTS files? :)
Re: Easy fix: replace BIND with DJBDNS
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? :)
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)??
RE: Easy fix: replace BIND with DJBDNS
Isn't the problem with how the protocol itself works?
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.
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.
Another option would be to rework DNS to use TCP rather than UDP.
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.
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.
"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.
- Xmas Round-up Ten top tech toys to interface with a techie’s Christmas stocking
- Exploits no more! Firefox 26 blocks all Java plugins by default
- Xmas Round-up Ghosts of Christmas Past: Ten tech treats from yesteryear
- Google embiggens its fat vid pipe Chromecast with TEN new supported apps
- Review Hey Linux newbie: If you've never had a taste, try perfect Petra ... mmm, smells like Mint 16