Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security Linux

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.

This discussion has been archived. No new comments can be posted.

Linux Has a Serious Security Problem That Once Again Enables DNS Cache Poisoning

Comments Filter:
  • 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)

      by bws111 ( 1216812 )

      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.

      • by F.Ultra ( 1673484 ) on Wednesday November 17, 2021 @02:38PM (#61996833)
        Which is a strange claim to begin with since there are no DNS handling in the Linux kernel AFAIK.
        • by FuegoFuerte ( 247200 ) on Wednesday November 17, 2021 @03:09PM (#61996937)

          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.

          • This isn't a side channel attack. Nor an attack on Linux. It's just a MITM attack that exploits a vulnerability in UDP/IPv4, a known unencrypted and insecure protocol. Sign or spoof. There are no alternatives.
            • Additional: "Under the new DNS spec, port 53 was no longer the default used for lookup queries. Instead, those requests were sent over a port randomly chosen from the entire range of available UDP ports. By combining the 16 bits of randomness from the transaction ID with an additional 16 bits of entropy from the source port randomization, there were now roughly 134 million possible combinations, making the attack mathematically infeasible." 134 million hardly falls into the territory of "infeasible". Unli
              • 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.

            • by bws111 ( 1216812 )

              Well if it is that, then why aren't Windows or FreeBSD affected?

              • by Anonymous Coward

                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.

                • by HiThere ( 15173 )

                  Read the BSD license. It's almost impossible to steal BSD code.

                • by bws111 ( 1216812 )

                  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).

              • by AleRunner ( 4556245 ) on Wednesday November 17, 2021 @04:14PM (#61997187)

                Well if it is that, then why aren't Windows or FreeBSD affected?

                Windows is affected. The article and summary are just trolling.

                On Windows Server 2019, the built-in Microsoft DNS server uses public-facing ports which makes it vulnerable

                (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.

              • 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.

          • by bferrell ( 253291 ) on Wednesday November 17, 2021 @09:48PM (#61997905) Homepage Journal

            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.

        • Systemd says hold my beer!

    • Re: (Score:2, Offtopic)

      by Opportunist ( 166417 )

      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.

  • by Anonymous Coward

    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.

    • by Junta ( 36770 )

      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)

        by shoor ( 33382 )

        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.

          • by shoor ( 33382 )

            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

            • "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

              • by shoor ( 33382 )

                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

  • by Spazmania ( 174582 ) on Wednesday November 17, 2021 @02:25PM (#61996805) Homepage

    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.

    • by Burdell ( 228580 ) on Wednesday November 17, 2021 @02:47PM (#61996865)

      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.

      • by Anonymous Coward

        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

        • 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?

      • yes if you have DNSSEC and DANE you are protected.

      • 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.

    • by F.Ultra ( 1673484 ) on Wednesday November 17, 2021 @02:58PM (#61996893)
      Well they claim 100% success in their paper, they used 3500 AWS instances to carry out the attack.
      • Right, but most real DNS servers are behind firewalls, you don't have the server with it's pants down on the open internet

        • by AmiMoJo ( 196126 )

          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.

          • 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

    • by bws111 ( 1216812 ) on Wednesday November 17, 2021 @03:13PM (#61996953)

      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.

    • by peterww ( 6558522 ) on Wednesday November 17, 2021 @05:20PM (#61997363)

      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?
      Out of the 157,186,029 registered .COM domains, 4,383,591 of them are DNSSEC signed.
      (https://www.statdns.com/)

      • honestly, why do we have to have issues like this to force people to add security...

        just add DNSSEC and DANE now !

        • 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

    • by vadim_t ( 324782 )

      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

  • by F.Ultra ( 1673484 ) on Wednesday November 17, 2021 @02:47PM (#61996869)
    Not sure why ArsTechnica left it out but in the paper they also describe Windows 10 (DoS by exhausting memory) and Windows Server 2019 as vulnerable.
    • by AmiMoJo ( 196126 )

      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.

      • That where for the DNS client in Windows 10, the DNS server in WIndows Server 2019 was as wide open for cache poisoning as BIND on Linux, but they ignored to mention that detail in the article.
  • by peppepz ( 1311345 ) on Wednesday November 17, 2021 @02:59PM (#61996895)

    allows hackers to send victims to maliciously spoofed addresses masquerading as legitimate domains, like bankofamerica.com

    ...where they will find a browser error page, because hackers can't fake bankofamerica.com's TLS certificate.

    • Limited also by any reasonably competent network configuration that wouldn't allow arbitrary, anonymous outside ICMP queries against public-facing servers.

  • *ducking head*

  • Calling this a side channel would be saying that a 16 or 32-bit value could qualify as a "secret". Don't make me laugh. Sign DNS records and enforce it.
  • 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

    • by HiThere ( 15173 )

      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.

      • My analysis is that you should block ICMP. This isn't news.

        • by caseih ( 160668 )

          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.

          • 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.

        • by nyet ( 19118 )

          Idiotic.

  • Every time I run the dig command, it always returns 127.0.0.53, so it's coming from itself and therefore must be trustworthy!
  • "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."
  • Most sites use SSL now, even if the DNS entry is poisoned the fake website would fail the SSL cert check. You would need to poison both the sites DNS entry as well as the cert providers entry and even then wouldn't you need the cert providers private key so that public key already installed on the user's pc matches? Not too many HTTP sites as opposed to HTTPS when it comes to banking and other secured services.

"Yes, and I feel bad about rendering their useless carci into dogfood..." -- Badger comics

Working...