This seems pretty unlikely with ECC modules. Worst reported error rate for regular RAM was 1 bit per hour per GB (via wikipedia) while other reports claim it'd take a century for that same amount of error. Regardless, this is ever more reason to use something like TLS to initiate a trusted identity with another party. Even in the null cipher case, it's useful to exchange a certificate.
Even with regular non-ECC modules, it seems like the odds of this affecting you are very very low. But the sheer number of operational computers probably means that the likelihood that at any given moment this is impacting someone's DNS query is probably fairly high.
New DNS hijacking technique exploits RAM errors
11–20 of 29 posts
Re: New DNS hijacking technique exploits RAM errors
#12Earlier quoted context omitted.
How about Google.com or Facebook.COM?
As far as I can tell, most or all of the one-bit errors on those are already registered by typosquatters.
Re: New DNS hijacking technique exploits RAM errors
#13I wonder how likely these errors are
> Normally a couple hundred IPs a day will visit popular bitsquatted destinations. #blackhat https://twitter.com/#!/dakami/status/98910873044791297
Re: New DNS hijacking technique exploits RAM errors
#14Re: New DNS hijacking technique exploits RAM errors
#15Would this not be compensated in the end-to-end TCP checksumming? And couldn't the traffic to bit-squatting domains be accounted for by the myriad bots that constantly scan the web on port 80?
Re: New DNS hijacking technique exploits RAM errors
#16Would this not be compensated in the end-to-end TCP checksumming? And couldn't the traffic to bit-squatting domains be accounted for by the myriad bots that constantly scan the web on port 80?
DNS is not a TCP protocol.
The likelihood of a bit-flip is very uncommon. Even taking into account the volume of computers out there, the likelihood of a bit-flip at the exact spot (in the domain name) and moment of a DNS lookup (before the checksum is calculated) is astronomically uncommon. This article is garbage.
Re: New DNS hijacking technique exploits RAM errors
#17Earlier quoted context omitted.
DNS is not a TCP protocol.
It can be either TCP or UDP. Regardless, UDP has a checksum as well. The likelihood of a bit-flip is very uncommon. Even taking into account the volume of computers out there, the likelihood of a bit-flip at the exact spot (in the domain name) and moment of a DNS lookup (before the checksum is calculated) is astronomically uncommon. This article is garbage.
Re: New DNS hijacking technique exploits RAM errors
#18Let's be charitable and say that every single one of those is connected to the internet 24x7 and they love microsoft so much that they visit the url every hour, so 24 times a day. To get even more accommodating, let's imagine every single computer in the world has a single bit error occur every hour as well, right before they head to microsoft.com.
In that case you'd expect about 3 hits a day.
I'm sure it can happen, but I'd be surprised if most of the traffic wasn't caused by other things. I can't be the only one who noticed in mic2osoft.com the number 2 is only two keys away from r. It may not be the most common typo in the world, but I bet the odds are a lot higher than 1 in 8.5 billion.
I almost think it's an inside joke, Kaminsky sounded just a wee bit too blown away while he was raving about the presentation last night. Or maybe that was just the booze tallking.
Re: New DNS hijacking technique exploits RAM errors
#19One bit in one gigabyte of RAM is 1 in 8,589,934,592. Wolfram Alpha estimates there are "over one billion computers" in the world. Let's be charitable and say that every single one of those is connected to the internet 24x7 and they love microsoft so much that they visit the url every hour, so 24 times a day. To get even more accommodating, let's imagine every single computer in the world has a single bit error occur…
Re: New DNS hijacking technique exploits RAM errors
#20This seems pretty unlikely with ECC modules. Worst reported error rate for regular RAM was 1 bit per hour per GB (via wikipedia) while other reports claim it'd take a century for that same amount of error. Regardless, this is ever more reason to use something like TLS to initiate a trusted identity with another party. Even in the null cipher case, it's useful to exchange a certificate.
Sections 7 and 8 of this paper [1] discuss inducing memory faults and potential countermeasures. Specifically they indicate that many desktop PCs shipped without ECC hardware at the time of writing (2003). I'm not sure to what extent that's still true, but I imagine it could be a problem for the masses of cheap/old hardware in use around the world. edit: I found some more recent numbers via [2]. Relevant quote: "Our…