Linux Has a Serious Security Problem That Once Again Enables DNS Cache Poisoning (arstechnica.com) 66
shoor writes: As much as 38 percent of the Internet's domain name lookup servers are vulnerable to a new attack that allows hackers to send victims to maliciously spoofed addresses masquerading as legitimate domains, like bankofamerica.com or gmail.com. The exploit, unveiled in research presented today, revives the DNS cache-poisoning attack that researcher Dan Kaminsky disclosed in 2008. He showed that, by masquerading as an authoritative DNS server and using it to flood a DNS resolver with fake lookup results for a trusted domain, an attacker could poison the resolver cache with the spoofed IP address. From then on, anyone relying on the same resolver would be diverted to the same imposter site.
The sleight of hand worked because DNS at the time relied on a transaction ID to prove the IP number returned came from an authoritative server rather than an imposter server attempting to send people to a malicious site. The transaction number had only 16 bits, which meant that there were only 65,536 possible transaction IDs. Kaminsky realized that hackers could exploit the lack of entropy by bombarding a DNS resolver with off-path responses that included each possible ID. Once the resolver received a response with the correct ID, the server would accept the malicious IP and store the result in cache so that everyone else using the same resolver -- which typically belongs to a corporation, organization, or ISP -- would also be sent to the same malicious server.
The sleight of hand worked because DNS at the time relied on a transaction ID to prove the IP number returned came from an authoritative server rather than an imposter server attempting to send people to a malicious site. The transaction number had only 16 bits, which meant that there were only 65,536 possible transaction IDs. Kaminsky realized that hackers could exploit the lack of entropy by bombarding a DNS resolver with off-path responses that included each possible ID. Once the resolver received a response with the correct ID, the server would accept the malicious IP and store the result in cache so that everyone else using the same resolver -- which typically belongs to a corporation, organization, or ISP -- would also be sent to the same malicious server.
the title couldn't be more slanted... (Score:1, Offtopic)
Quote: "Linux Has a Serious Security Problem That Once Again Enables DNS Cache Poisoning"
Well... It will soon be patched. Can you say the same about Windows or macOS serious security problems? One because they take a hell of a time (Microsoft), the other because people is unaware of the security problems (and thus unprotected) because the company denies any info (Apple).
Re: (Score:3, Insightful)
Where is the supposed 'slant'? TFA says the problem is in Linux itself. Whether or not it 'will be fixed' is immaterial - as of now it has a security problem.
Re:the title couldn't be more slanted... (Score:5, Interesting)
Re:the title couldn't be more slanted... (Score:5, Interesting)
There's no DNS handling directly, but after looking at the actual article this is a sidechannel attack on the kernel which can let the attacker determine the ephemeral port being used for the DNS request, making the DNS cache poisoning possible (because the transaction ID is only 16 bits, so once the port # is known the server can be flooded until the right transaction ID is found).
So, this affects pretty much all DNS servers (I'm not sure if it's actually all, but the article lists BIND, Unbound, and dnsmasq by name) running on Linux, but does not affect that same software running on Windows, BSD, etc. So it really is a vuln in the Linux network stack that enables the sidechannel attack.
Re: the title couldn't be more slanted... (Score:1)
Re: the title couldn't be more slanted... (Score:2)
Re: (Score:3)
Seems like an obvious mitigation would be to use Linux's AnyIP feature to allow DNS servers to bind to a random source address for each query, which would add ~64 bits of entropy for a total of ~91 bits. I'm not sure if that would qualify for "infeasible" but it's certainly a lot closer to it.
I guess it won't help for authoritative servers without v6, but those servers need to get v6 anyway. They also need to sign their zones, which would definitively fix this.
Re: (Score:2)
Well if it is that, then why aren't Windows or FreeBSD affected?
Re: (Score:1)
Well if it is that, then why aren't Windows or FreeBSD affected?
Because Microsoft "stole" a bunch of networking code from FreeBSD.
But also, the Linux and FreeBSD kernels don't have DNS servers compiled in to them, so it's not really a Linux, FreeBSD, or Windows thing. It's a "DNS package you installed" thing.
Re: (Score:3)
Read the BSD license. It's almost impossible to steal BSD code.
Re: (Score:2)
If it is a MITM attack, and not a side-channel attack or a Linux attack, then all OS's would be vulnerable no matter who they "stole" code from. Since only Linux is affected, it clearly is NOT a MITM attack (or if it is, it is an MITM attack that relies on a flaw in Linux).
Re: the title couldn't be more slanted... (Score:5, Informative)
Well if it is that, then why aren't Windows or FreeBSD affected?
Windows is affected. The article and summary are just trolling.
(see paper [ucr.edu])
Though on windows 10 it says the exploit can be difficult but it should also be possible to DoS the entire system.
Server? (Score:2)
Well if it is that, then why aren't Windows
Wait, it's 2021, are there still Microsoft Windows server connected to the internet around?
I mean even general server, not specifically DNS server as per today's vulnerability.
or FreeBSD affected?
No matter what the title says, BIND, dnsmasq,etc. would also by affected if they happed to run atop a BSD kernel, too.
The whole idea of not having signed update is a security nightmare with, no matter the kernel atop of which the considered DNS server happens to run in particular.
Re:the title couldn't be more slanted... (Score:4, Informative)
No, it's NOT a "side channel attack on the kernel" and it has nothing to do with ports, but transaction IDs in the DNS query responses from things that appear to be DNS servers. and it has nothing to do with the TCP stack, ONLY with DNS server responses.
A quick check shows ISC fixed poisoning back is 2013.
While the kernel may implement ICMP rate limiting to 1000 per second default, most DNS rate limits happen at MUCH lower set points configured in the DNS server.
While TFA is mildly interesting, it also a reference to implementations that damned near no one uses; Effectively, the conditions are akin to:
"If you leave your front door wide open ANYONE can steal your TV"
I'll not speculate as to motives for trumpeting a study from 2020 with such esoteric and BAD configurations being referenced in late 2021.
Re: (Score:2)
Systemd says hold my beer!
Re: (Score:2, Offtopic)
C'mon, you know it's clickbait to invite the Winfanboys to gloat and the Linuxfanboys to defend, descending into petty bickering and namecalling, to ensure the dick measuring content creates clicks.
Just don't take the bait and move on.
Fatal Flaw (Score:1)
The fatal flaw in this summary is a double whammy: It starts out waxing lyrically with history, meaning it isn't actually a summary, and then forgets to mention just how this supposedly-solved vulnerability was revived. No amount of shouting "hackers!" is going to cover for that wasting of everyone's time.
Re: (Score:2)
Yeah, they 'summaried' the 2008 news and skipped over the new news (that they found a way to attack through ICMP redirects that is actually a linux kernel issue, not as I had guessed some userspace issue attributed to Linux).
Re: (Score:3, Informative)
I'm the one who submitted the article, and they took the headline not from me but from the article I referenced. They also didn't take my summary but just quoted the beginning of the article. What I wrote was:
Ã--
Submission + - Exploit Lets Spoofed Addresses Masquerade as Legit on Linux Servers (arstechnica.com)
Submitted by shoor on Wednesday November 17, 2021 @01:09PM
shoor writes:
The exploit may allow malicious hackers to redirect inquiries to phishing and other malware sites that are replicas of legitimate sites. A new DNS spec was supposed to randomize the port DNS queries come from, closing off an exploit that allowed attackers to introduce a malicious IP address into a DNS resolver's cache. Under the new spec, an ICMP probe can change internal state in the Linux Kernel in a way that can be observed through a side channel.
Re: (Score:3, Insightful)
The meat of the matter (taken from comments in here) is that tricky ICMP abuse allows a revival of DNS cache poisoning. So this goes up top. Then you follow up with a paragraph that reminds us of DNS cache poisoning, which (for the less informed among us, most will know) means that your queries for cache-poisoned sites end up at a poisoned destination, which in turn enables, say, phishing or malware being served. After that, you dig in just how the ICMP abuse works and how that enables the cache poisoning.
Re: (Score:1)
I appreciate the feedback, genuinely constructive criticism.
In my defense, I will say that I was somewhat hampered in my 'style' in that I wanted to be faithful to the original article, to summarize it, not my own thoughts. The original article used the word 'hacker', and I added 'malicious' because I deplore the way the word 'hacker' is casually assumed to mean someone with bad intentions. I was tempted to use the word 'cracker', but that term never caught on and I figured a lot of readers would just be
Re: (Score:1)
"Hacker" outside of its jargon file meaning has become a scare word that is best avoided entirely. I would also avoid "news" outlets using it, because they're going for the ignorant scare sensation. So I'd even suggest finding a better news source. Linking to the CVE, listmail, blog post, what-have-you might be a better option. Enough people here ought to be able to understand that, and if not a good summary or perhaps the discussion would step in. (If you are knowledgeable and need the discussion to clarif
Re: (Score:1)
Considering that what effort I did put in to making a cogent summary was ignored, it is maybe just as well I didn't put in more effort. Working hard on something and polishing it, and then having it ignored would have been very frustrating.
I've been following slashdot for a long time, and I appreciate it for what it does. Mainly I like the mod system that let's me filter out a lot of real junk. But it's certainly not perfect. And this experience doesn't encourage me to work hard on any future submission
Doesn't look practical (Score:5, Informative)
This attack doesn't look practical to me. First you're going to send 65k ICMP packets to figure out which UDP ports are currently open on the server. Then you're going to send another 65k packets to -each- open port in order to go through all the transaction IDs and hit the particular one that's needed for the fake response. And then it has to be a domain that's not DNSSEC protected or a resolver that doesn't validate DNSSEC.
The odds of seeing this attack in the wild are pretty low.
Re:Doesn't look practical (Score:5, Informative)
Despite many years of effort, the rate of DNSSEC signing is low. DNSSEC validation is common (because resolver software enables it by default and no other action is required in most cases), but DNSSEC signing for authoritative servers takes a fair amount of effort to get right and is still easy to screw up (which breaks all resolution for the domain), so major domains just don't use it.
For example, none of the following well-used domains are signed: google.com facebook.com apple.com microsoft.com amazon.com. IIRC slack.com's outage a few weeks ago was due to a mistake trying to enable DNSSEC, and then they disabled it.
Re: (Score:1)
So just like with IPv6, it's fair to say that DNSsec is a failed technology.
In both cases the tech people went all-out "tech" and managed to miss the mark on practical real-world problem solving. So instead of son-of-IPv4 everywhere, we're getting a good helping of GCNAT, and with that, further consumerisation of the intertubes. So instead of secured DNS, we get unsecured domains and/or various kinds of subtle trouble, some of them political and powermongering.
The thing that struck me with DNSsec is that i
Re: (Score:3)
Not really like IPv6, no. IPv6 mostly just extends the address length over v4; it's taking a long time to deploy because deploying a new L3 protocol with longer addresses is difficult.
I'm not quite as familiar with DNSSEC, but as far as I'm aware it does deliver on what you want. It's just that delivering on what you want involves doing the various things DNSSEC does... so actually rather like v6 after all?
Another reason for DNSSEC (Score:2)
yes if you have DNSSEC and DANE you are protected.
Re: (Score:1)
It would help a lot if more than... oh... 1 domain registry supported RFC 8078. That's how many there were last I checked, anyway.
Automation of signing key rollover would certainly help with the effort required, at least.
Re:Doesn't look practical (Score:4, Informative)
Re: (Score:3)
Right, but most real DNS servers are behind firewalls, you don't have the server with it's pants down on the open internet
Re: (Score:2)
There are lots of public DNS servers. I just checked a few of the popular ISPs in the UK, and found that Sky Broadband (90.207.238.97 and 90.207.238.99) and Zen Internet (212.23.3.100 and 212.23.6.100) both have publicly accessible DNS servers.
There are services like 1.1.1.1 (Cloudflare) and 8.8.8.8 (Google), and I've seen a lot of public wifi set-ups use public DNS servers instead of VPNing all traffic through their internal network.
Re: (Score:2)
You left out the whole "firewalls" and "pants down" parts of the comment.
Those were the important parts.
You left out both of the important details, and just focused on one very broad word.
You've been here for a few years, kiddo, figure out that I'm a former sysadmin, former systems programmer, current firmware programmer, and when I make technical observations, they're not wrong. Get a fucking clue, kid. You don't comprehend the difference between being behind a firewall vs "having your pants down?" Then wh
Re:Doesn't look practical (Score:5, Informative)
That was the old method. The new attack uses a flaw in Linux's ICMP handling that allows a side channel attack where you can infer the port. Then you only have to flood that port.
Re:Doesn't look practical (Score:5, Informative)
I've personally experienced the attack. Someone hijacked my ISP's resolver cache for a domain I happened to be visiting. It took a good hour or two of investigation to figure out it wasn't a misconfiguration anywhere, but an actual false record being returned for that record. This was 3 years ago.
Do you know how fast you can send 130k packets over the internet today? In a few seconds.
Even if you spent 30 minutes on the attack, you can hijack a domain for _an entire ISP_, or even way, way bigger targets than just a single ISP.
Do you know how many domains implement DNSSEC? .COM domains, 4,383,591 of them are DNSSEC signed.
Out of the 157,186,029 registered
(https://www.statdns.com/)
yes enable DNSSEC and DANE...now (Score:2)
honestly, why do we have to have issues like this to force people to add security...
just add DNSSEC and DANE now !
Re: (Score:2)
There are a lot of potential problems with implementing and maintaining DNSSEC. Among them, you can end up completely dropping all users from your entire domain indefinitely.
And DANE is pretty useless. Every user on the web has to install an add-on to their browser to take advantage of it. It's also just a bad solution, tying multiple systems together for little benefit. It combines name-server records, DNSSEC records, domain registration records, and TLS CA validation.... leading to a lot of complexity and
Re: (Score:2)
Even by pure brute force, that's already within the realm of possibility.
DNS has a maximum packet size of 576 octets for a 512 byte payload. 64K of those is 36 MB. That's tiny, half a second on a 1G line which can be had at home in many places.
How many open ports are there going to be? Even if you had to send 64K packets to each of the 64K ports, that's just 2.3 TB. On a 10 Gbit line you can do that in half an hour.
You can get a 10G upload by just renting a VM somewhere for the purpose if you can't have tha
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
Like clockwork...
Windows aswell (Score:3)
Re: (Score:2)
Probably because a denial of service attack is much less serious. You could knock out an ISP's or company's DNS server, if for some reason they were running Windows on it. That's not nearly as bad as being able to spoof most major internet sites like google.com or facebook.com.
Re: (Score:2)
The problem is mitigated by SSL (Score:4, Insightful)
Re: (Score:1)
Limited also by any reasonably competent network configuration that wouldn't allow arbitrary, anonymous outside ICMP queries against public-facing servers.
I toldja to use Windows (Score:1)
*ducking head*
Re: (Score:3)
On Windows Server 2019, the built-in Microsoft DNS server uses public-facing ports which makes it vulnerable
Re: (Score:1)
I toldja to use Commodore 64's
Re: (Score:2)
Sign or Spoof (Score:1)
Regressions are bad (Score:2)
After the thread on software testing, where there was quite a nice debate on the importance of testing and documenting, it shocks but doesn't surprise me that Linux suffered a security regression. It happens, although with better testing it would be less likely to make it into what is essentially a brown paper bag release. We're never going to see Linux reach SEL4 standards, the kernel is too complex, but we aught to be able to reach the point where bugs of this kind just don't make it into the mainstream k
Re: (Score:2)
Some people are saying is really is a Linux kernel error, and others are saying it's user installed applications, and others are saying "it's so diffiult and noisy to use that it will never show up in the wild".
It would be nice if someone could point to a trustworthy analysis.
Re: (Score:2)
My analysis is that you should block ICMP. This isn't news.
Re: (Score:3)
And yet ICMP is still a very useful network diagnostic tool. Drives me nuts that Windows disables ICMP by default in Windows Defender on a local lan. I'd rather see this fixed in a way that preserves the usefulness of ICMP. I like to be able to ping my VPS, to see that my local network connectivity is okay and that my vps and vpn will be reachable.
Re: (Score:2)
It's pretty normal to restrict ICMP access by IP address in the firewall, so that you can pink your VPS from your dev computers but not from the wild.
One simple technique is to add a VPN (not a VPN service, just run it on your VPS) and restrict ICMP to the VPN.
Re: (Score:2)
Idiotic.
I Know I'm Safe (Score:2)
and water is wet /s (Score:2)
Wouldn't SSL make this poisoning pointless? (Score:1)
Mem cached servers might be a bigger problem (Score:1)