Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security Linux

Linux Has Been Bitten By Its Most High-Severity Vulnerability in Years (arstechnica.com) 110

Posted by msmash from the security-woes dept.
Cognitive Dissident writes: Ars Technica is reporting a major new vulnerability in Linux. Named "Dirty Pipeline" it involves abuse of 'pipes' at the shell level as you might guess.

The name Dirty Pipe is meant to both signal similarities to Dirty Cow and provide clues about the new vulnerability's origins. "Pipe" refers to a pipeline, a Linux mechanism for one OS process to send data to another process. In essence, a pipeline is two or more processes that are chained together so that the output text of one process (stdout) is passed directly as input (stdin) to the next one. Tracked as CVE-2022-0847, the vulnerability came to light when a researcher for website builder CM4all was troubleshooting a series of corrupted files that kept appearing on a customer's Linux machine. After months of analysis, the researcher finally found that the customer's corrupted files were the result of a bug in the Linux kernel.


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

Linux Has Been Bitten By Its Most High-Severity Vulnerability in Years More

Linux Has Been Bitten By Its Most High-Severity Vulnerability in Years

Comments Filter:
  • is snickering at the thought of hundreds of professional TV Anchors saying "Dirty Pipeline". Bravo sir! It's been ages since we've pulled one of these over on them.

    • Re: (Score:1)

      by DarkOx ( 621550 )

      Why some lefty twit like you says it every other day; usually talking about oil though.

      • You are mistaken. When lefties speak of a "dirty pipeline", we're usually referring to what was left in your mom after our farm animals finished running dicks up her birth canal.

        I'm glad she didn't try for child support after you came along, though. I bet the bill for your special ed costs was formidable.

        • Re: (Score:2)

          by DarkOx ( 621550 )

          That's not a polite way to talk about your siblings and yourself Miles...

          • If you were able to read English without help, you'd know I was referring to you. Maybe you'd better go get your mom and ask her to read the comment to you. She'll probably be able to fill in some juicy details. ;-)

      • The only person talking about oil is you.

    • I think the real question is, have they performed deep penetration testing on the dirty pipe?

  • Only affects kernel 5.8 and later (Score:3)

    by Guy Smiley ( 9219 ) on Tuesday March 08, 2022 @10:36AM (#62336335)
    Reading the article, one critical bit of information omitted from the summary, and only appearing late in the article is that this bug was first introduced in kernel 5.8, so does not affect common installations like RHEL 8.

    • Re: (Score:2)

      by MagicM ( 85041 )

      According to RedHat's page [redhat.com], RHEL 8 is affected.

      • Re: (Score:3)

        by MagicM ( 85041 )

        My mistake. Apparently RHEL 8 is simultaneously affected and not affected.

        Note that PIPE_BUF_FLAG_CAN_MERGE flag attack vector is not available in Red Hat Enterprise Linux 8 and thus the currently known exploits leveraging this flag do not work. The underlying issue (lack of proper pipe_buffer structure initialization) is still present though and other novel ways leading to successful exploitation cannot be fully ruled out.

        • > My mistake. Apparently RHEL 8 is simultaneously affected and not affected.

          It may have this vulnerability but it's not affected by this exploit.

        • Re: (Score:2)

          by necro81 ( 917438 )

          My mistake. Apparently RHEL 8 is simultaneously affected and not affected.

          It's a Schrödinger's Exploit.

        • Schroedinger's distro.

        • My mistake. Apparently RHEL 8 is simultaneously affected and not affected.

          It's Schrodinger's vulnerability, so you won't know if it's vulnerable unless you look inside the CPU.

      • Re: (Score:2)

        by bws111 ( 1216812 )

        That page says this: Note that PIPE_BUF_FLAG_CAN_MERGE flag attack vector is not available in Red Hat Enterprise Linux 8 and thus the currently known exploits leveraging this flag do not work. The underlying issue (lack of proper pipe_buffer structure initialization) is still present though and other novel ways leading to successful exploitation cannot be fully ruled out.

        So, no, RHEL 8 is NOT affected by this particular vulnerability.

    • Reading the article, one critical bit of information omitted from the summary, and only appearing late in the article is that this bug was first introduced in kernel 5.8, so does not affect common installations like RHEL 8.

      The article further states that the bug was there all along; it was kernel 5.8 that offered an easy way to exploit it.

      • It looks like this is a privilege escalation attack, allowing any account to obtain root privileges. So that means that malicious apps can gain root when run. I didn't see anything about attackers being able to "leap in" using something like a malicious web page or bluetooth transmitter, though. It makes me think people are safe so long as they aren't running sketchy apps.

        Does anyone know if there is some way to use this to "push in" to a system if it isn't already running a trojan app?

        And anyway, the ar

        • Re: (Score:2)

          by HiThere ( 15173 )

          I think it's more dangerous than you are suggesting, but Debian issued an update to stable last night (or was it the night before) so I suspect it's been patched if your system is up to date. And for older installs the system isn't vulnerable to this attack, though the basis of the vulnerability is present.

          OTOH, yes, it's a privilege escalation attack. But that means that any attack that's successful on any user can be escalated to a root attack. And this would include vulnerabilities in web browsers and

  • Oh! This security bug affects Linux? Well...uh.. then it doesn't count.. and will get patched...so it's fine.

    • Re: (Score:2)

      by jbengt ( 874751 )

      . . . will get patched . . .

      Already been fixed last month.

    • Privilege escalation bugs are common in every OS. The reason is because there is a massive attack surface (the OS syscall interface) that was mostly designed without security in mind. It is also why Windows has more security problems than Linux, because the interface exposed is much larger.

      The end result is that you should not rely on local privileges as the primary defense in your security model. It can be helpful part of a defense in depth, but it should not be the primary defensive layer (especially sinc

    • Not found in OpenBSD. No need to jump over to MS just yet.

    • No no I'm letting you have this moment. They are so rare for you M$ guys.

      By 'most severe vulnerability in years' they still just mean a local priv escalation though.

    • only affects Linux with bleeding edge kernel... not a concern to most of us running stable long term patched stuff.

      *yawn*

      • Re: (Score:1)

        by ebvwfbw ( 864834 )

        So it's not just me. I tried a bunch of test VM systems I have. Some of them with some 6 month old kernels. Nothing happens. It says it's successful. It wasn't.

        Yes, *Yawn*. By the title you'd think - run over the women and children! This needs to be fixed NOW!

  • You should have used Win~& v` f}*q [NO CARRIER]

    • We know you're joking but there's going to be knee-jerk OS swapping going on. Every OS has its troubles but we should never dogpile on it if the authors reveal the issues in good faith. Note that if this had occurred in Windows or OSX then you probably wouldn't find out until after you're hacked. Then the vendor will claim you're holding it wrong. Either way your insurance claim is going to fail but at least Linux never tried to say it was 100% bug-free. It isn't. No software is.

      • Swap our your old Linux for a shiny new Linux and then you won't have this bug. It's kind of why enterprise customers pay Red Hat, SUSE, etc.

        • Re: (Score:2)

          by sjames ( 1099 )

          OTOH, I upgrade only when necessary and prefer LTS distro versions, so no kernel I'm using has the vulnerability. When upgrade time comes, I'll skip the vulnerable versions.

          • It should be present in Ubuntu 20.04.4 (Focal Fossa) LTS running kernel 5.13 (the flaw is in kernel 5.8 and later). When I checked, Canonical hasn't updated their page on the issue. [ubuntu.com]. I but I expect "needs triage" to move to "vulnerable" in short order.

            While you wait for an exploit known for over 2 weeks to be fixed, you can feel comforted that a fix will eventually arrive thanks to the Long-Term Support guarantees.

            • Re: (Score:2)

              by sjames ( 1099 )

              I'm still on 18.04.6 (Bionic Beaver) because I didn't need to upgrade yet and it is still within support.

              Focal Fossa ships with kernel 5.4 (not vulnerable).

              • If you update on Focal Fossa you get 5.13 because you'll be moved onto 20.04.4.

                Ubuntu 20.04.0 and 20.04.1 LTS ships with v5.4
                Ubuntu 20.04.2 LTS ships with v5.8
                Ubuntu 20.04.3 LTS ships with v5.11
                Ubuntu 20.04.4 LTS ships with v5.13

                But remember that 20.04.0 has fallen out of LTS. and is now in ESM (Extended Support Maintenance).

                You're pretty safe if you're on v5.4 though. It doesn't falls out of support until year 2025. After that you'll want to consider moving to v5.15 to take you out to yeare 2027.

                • Re: (Score:2)

                  by sjames ( 1099 )

                  Booting the 5.4 kernel remains an option though and the packages are still there. So nobody's stuck.

  • Details ... (Score:3)

    by kbahey ( 102895 ) on Tuesday March 08, 2022 @11:42AM (#62336569) Homepage

    Here are the details [cm4all.com] from the person who discovered the vulnerability.

    Note that the vulnerable kernels are 5.16.x, 5.15.x and 5.10.x. So if you are running, for example, Ubuntu 20.04 LTS (like I am), you are not vulnerable since it has 5.4.0.

    • Good to know the LTS / long term support release was more stable as we would all hope. And thanks for the post, I can rest easy over here myself as I'm also on the 20.04 LTS version.

  • "Pipe" refers to a pipeline, a Linux mechanism for one OS process to send data to another process.

    A Unix mechanism to be sure, having pre-dated Linux by 20 years.

  • Somewhat limited relevancy (Score:3)

    by gweihir ( 88907 ) on Tuesday March 08, 2022 @11:48AM (#62336591)

    First, it only applies to kernels 5.8 and newer. I found one in my collection in Gentoo. My Debian installations (oldstable) are not even affected. This will also make it irrelevant on many Android installations. Second, this is a _local_ privilege escalation. You know, the kind of thing that on Windows does not even get patched out of schedule anymore, because it is so easy to do there. Still a potential problem, but an attacker has to get in first.

    So yes, this needs a patch. But any kind of grandiose headline is simply hyperbole.

    • 5.8 was released in 2020, it's not a recent version and Ubuntu 20.04 LTS is using 5.15 (assumed vulnerable). Definitely a current issue. And it needs to be addressed because a local root escalation vulnerability like this means that any and all remote code execution compromises/exploits have to be considered remote root escalation vulnerabilities. Fortunately the Linux kernel team had it patched shortly after it was discovered (and before it was announced publicly) and the patches have likely rolled out to

      • My Ubuntu 20.04 is using 5.4. Also reported by another poster. At least get your facts right if you're going to get all preachy. And none of your preaching changes the fact that Windows is so rife with local exploits that everyone serious about security just assumes it is impossible to secure against local privilege escalation.

        • Re: (Score:2)

          by gweihir ( 88907 )

          My Ubuntu 20.04 is using 5.4. Also reported by another poster. At least get your facts right if you're going to get all preachy.

          The preachy idiots do not care about facts. They care about acting all superior and telling everybidy how great and knowledgeable they are. If somebody behaves like this guy, it is a good indicator his information is faulty and his conclusions are worthless.

      • Re: (Score:2)

        by gweihir ( 88907 )

        If you have a remote code execution vulnerability, you are already screwed. This does somewhere between nothing and very little to make matters worse. Also, I guess you are unfamiliar with long-term supported kernels. You mau want to correct that shortcoming by looking at www.kernel.org. Here is a hint: 2 of 6 kernels with long-term support are affected.

    • > My Debian installations (oldstable) are not even affected.

      It appears to me that Debian Stable is unpatched after public disclosure, two weeks after the kernel update and one week after private disclosure to the distros. For a two line patch that's obvious on its face.

      I hope I can't read...

      • Re: (Score:2)

        by gweihir ( 88907 )

        > My Debian installations (oldstable) are not even affected.

        It appears to me that Debian Stable is unpatched after public disclosure, two weeks after the kernel update and one week after private disclosure to the distros. For a two line patch that's obvious on its face.

        I hope I can't read...

        Debian is slow. A reason to run oldstable, which is not affected. Also, the Debian maintainers are not prone to hysterics, unlike some people here. Patching this is not that urgent. If you have a remote code execution vulnerability, you are already pretty much screwed. If you do not, you typically have no immediate problem.

        • Re: (Score:2)

          by AvitarX ( 172628 )

          I would think that completely destroying local security is a pretty big deal.

          Isn't it still that the biggest threats are internal?

          • Re: (Score:2)

            by gweihir ( 88907 )

            I would think that completely destroying local security is a pretty big deal.

            Isn't it still that the biggest threats are internal?

            No. The biggest threats are malware and remote exploits. Local exploits are something that you should patch in a timely manner on Linux (i.e. within a few weeks), but nothing to get hectic about. On windows, local exploits are so numerous that you basically assume if anybody gets any local user the machine is fully compromised.

            • Re: (Score:2)

              by gweihir ( 88907 )

              To clarify: Yes, the some of the biggest threats from the side of enterprise risk-management are insider-threats. But there is no basically connections to local privilege elevation exploits. Insider threats are about people within an organization abusing rights they legitimately have or illegitimately but within that autorisation framework could obtain, e.g. by claiming to a clueless superior that they need these right to do their job. In almost all cases, these "insiders" are not IT experts and could not u

      • Re: (Score:1)

        by lexios ( 1684614 )

        It appears to me that Debian Stable is unpatched after public disclosure, two weeks after the kernel update and one week after private disclosure to the distros. For a two line patch that's obvious on its face. I hope I can't read

        If you missed the next line just below vulnerable on https://security-tracker.debian.org/tracker/CVE-2022-0847 [debian.org] then yes, read a bit more carefully next time, please.

        • Re: (Score:2)

          by gweihir ( 88907 )

          It appears to me that Debian Stable is unpatched after public disclosure, two weeks after the kernel update and one week after private disclosure to the distros. For a two line patch that's obvious on its face.

          I hope I can't read

          If you missed the next line just below vulnerable on https://security-tracker.debian.org/tracker/CVE-2022-0847 [debian.org] then yes, read a bit more carefully next time, please.

          Well, to be fair, regular Bullseye is vulnerable. Bullseye-security is not. There are both good reasons for having the security repo in your sources lists and for not having it in there.

  • 10 months of debugging staring a couple octets? That's an almost inhuman amount of patience... I'm kinda glad it paid off for him - it's rare to find something like this!

    • Re: (Score:2)

      by Make ( 95577 )

      The actual debugging only took me only one (long) day - plus an hour here and there but with no useful result. 10 months is just wallclock time, not user time ;-)

  • Imagine if I had switched to Linux like everyone wanted me to :O Sometimes it pays to not listen

  • The real kicker is that the patch [kernel.org] re-enables safety flags that were removed> (line 544). [github.com]

    Double-kicker is that Debian apparently hasn't pushed the patch in the week that they had so 'stable' is vulnerable [debian.org]. It's hard to believe, so please correct if I missed it.

    • Re: (Score:2)

      by olau ( 314197 )

      If you go to the developer page [debian.org], you can see that it was uploaded to the security repository [debian.org].

      The security repository is enabled when you install stable. Why the packages are not just merged directly into stable, I have no idea. Perhaps it has to do with mirroring?

    • Update: the package was updated yesterday and propagated overnight.

      However, note that the new archive name is 'stable-security'. You might need to update your pins if you upgraded from Buster and you're not seeing the update now. I put in a pull request to add that to the release notes.

  • The researcher—Max Kellermann of CM4all parent company Ionos—eventually figured out how to weaponize the vulnerability to allow anyone with an account—including least privileged "nobody" accounts—to add an SSH key to the root user's account. With that, the untrusted user could remotely access the server with an SSH window that has full root privileges.

    This is one of many reasons why you should never allow root to log in via ssh (the primary reason is for accountability: requiring sud

    • You're not reading that right. They aren't coming in as root through ssh. They are gaining root in an ssh session. Sudo can be used for this exploit.

      See an example screenshot of the exploit in action here:
      https://www.bleepingcomputer.c... [bleepingcomputer.com]

    • I think you didn't understand it. The attacker can overwrite sudo with their own program that launches a shell without doing any logging or asking passwords. then simply putting sudo back. No one sees anything, except that webserver of yours is now mining bitcoins for them and sending tons of porn spam.

    • Re: (Score:2)

      by Junta ( 36770 )

      That's too fixated on the specific example given. In your configuration, the attacker would instead just overwrite /etc/sudoers to achieve the same end.

      Root login being disabled in ssh would not work to mitigate this vulnerability.

  • Both of these individuals refuse to recognize security vulnerabilities as something distinct and insist on treating them as "just another bug".

    Except they are not. Letting someone silently gain remote access to your system (in a worst case scenario) is much different from a device driver causing a crash or something.

    Until the Linux maintainers prioritize security vulnerabilities as they should be, then it's hard to consider Linux secure. Honestly the Linux attitude is pretty much the same attitude Microsoft

  • Done.

    Now to update existing installs.

  • I see it again in this post where shell pipes are used to pass *text* between processes. This is not correct (at least on *nix), because every byte of output is passed unmolested to the connected process. This is behavior is quite useful fo stuff like this:

    ssh remotehost.domain 'tar czf - *' | tar xzf -

Slashdot Top Deals

Don't panic.

Close