Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Thursday January 27 2022, @04:34AM   Printer-friendly

Major Linux PolicyKit security vulnerability uncovered: Pwnkit:

Polkit, formerly known as PolicyKit, is a systemd SUID-root program. It's installed by default in every major Linux distribution.

[...] This vulnerability is easy to exploit. And, with it, any ordinary user can gain full root privileges on a vulnerable computer by exploiting this vulnerability in its default configuration. As Qualys wrote in its brief description of the problem: "This vulnerability is an attacker's dream come true."

[...] Why is it so bad? Let us count the ways:

  • Pkexec is installed by default on all major Linux distributions.
  • Qualys has exploited Ubuntu, Debian, Fedora, and CentOS in their tests, and they're sure other distributions are also exploitable.
  • Pkexec has been vulnerable since its creation in May 2009 (commit c8c3d83, "Add a pkexec(1) command").
  • An unprivileged local user can exploit this vulnerability to get full root privileges.
  • Although this vulnerability is technically a memory corruption, it is exploitable instantly and reliably in an architecture-independent way.
  • And, last but not least, it's exploitable even if the polkit daemon itself is not running.

[...] While we know Linux can be attacked, Solaris and other Unix systems may also be vulnerable. We do know, however, that OpenBSD can't be attacked by exploits using this vulnerability.

Red Hat rates the PwnKit as having a Common Vulnerability Scoring System (CVSS) score of 7.8. This is high.

When used correctly, Polkit provides an organized way for non-privileged processes to communicate with privileged processes. It is also possible to use polkit to execute commands with elevated privileges using the command pkexec followed by the command intended to be executed with root permission.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Informative) by Anonymous Coward on Thursday January 27 2022, @07:46AM (10 children)

    by Anonymous Coward on Thursday January 27 2022, @07:46AM (#1216098)

    If you run Linux, especially GNOME, check if you have pkexec and PolKit. Despite what some say, it is not a systemd component (but is is a freedesktop.org project). Even if you are on a systemd-free installation you may be running it and even if you are on systemd you may not be running it. Check your updates anyway. To illustrate, none of our systemd servers had it installed but two of our Devaun desktops did.

    Starting Score:    0  points
    Moderation   +5  
       Interesting=1, Informative=4, Total=5
    Extra 'Informative' Modifier   0  

    Total Score:   5  
  • (Score: 5, Informative) by Snospar on Thursday January 27 2022, @08:38AM (5 children)

    by Snospar (5366) Subscriber Badge on Thursday January 27 2022, @08:38AM (#1216113)

    Running Void Linux here which is systemd free (using runit instead). I had pkexec version 0.119 which was already safe (0.118 was the last dangerous version) but I've upgraded to 0.120 just to be sure. Always useful in these discussions to make it clear which versions are dodgy and which have been fixed.

    --
    Huge thanks to all the Soylent volunteers without whom this community (and this post) would not be possible.
    • (Score: 0) by Anonymous Coward on Thursday January 27 2022, @08:48AM

      by Anonymous Coward on Thursday January 27 2022, @08:48AM (#1216114)

      I just checked my pkexec (Arch derivative distro) - version 0.120. As almost always, by the time an article hits "THE HEADLINES!!!" the fix has already come and been through the regular updates. Yawn...

    • (Score: 0) by Anonymous Coward on Thursday January 27 2022, @09:23AM

      by Anonymous Coward on Thursday January 27 2022, @09:23AM (#1216120)

      I thought about that but decided against it. All of the major distros already patched it as have their downstreams. But the problem is that what versions are or are not dodgy can be specific to particular distros and particular releases of distros.

    • (Score: 0) by Anonymous Coward on Thursday January 27 2022, @10:26PM

      by Anonymous Coward on Thursday January 27 2022, @10:26PM (#1216306)

      You are thinking of a different vulnerability. The one fixed in 0.119 was a problem with dbus. Even 0.120 is vulnerable to this. You will need to get a 0.120 patched with a fix, or disable pkexec as a workaround (probably a painless one for personal use, as everyone uses sudo, not pkexec, although corporate users sometimes prefer pkexec).

      Documentation is scarce because most distros for some reason no longer report exact package versions in their security bulletins (users shouldn't have to worry their pretty little heads over what version of software they have), but you can see the security tickets for Gentoo here [gentoo.org].

    • (Score: 2) by Runaway1956 on Friday January 28 2022, @12:42AM (1 child)

      by Runaway1956 (2926) Subscriber Badge on Friday January 28 2022, @12:42AM (#1216337) Journal

      +1 informative

      However, MX introduces some confusion.

      $ pkexec --version
      pkexec version 0.105

      .105 is obviously not up to date with .118, .119, or .120.

      Package manager says that mx-pkexec provides my pkexec, and it is at version 21.03.02. It isn't clear to me, based on that, whether I'm patched or not patched.

      Internet search "is my pkexec vulnerable" leads to https://support.cpanel.net/hc/en-us/articles/4420357490455-Polkit-pkexec-vulnerability-CVE-2021-4034 [cpanel.net]

      zgrep -E 'CVE-2021-4034' /usr/share/doc/policykit-1/changelog.Debian.gz
      If it is not updated, the output will be blank.

      Results say

      $ zgrep -E 'CVE-2021-4034' /usr/share/doc/policykit-1/changelog.Debian.gz
          * Local Privilege Escalation in polkit's pkexec (CVE-2021-4034)

      It seems that my version is patched, despite being multiple versions out of date.

      • (Score: 0) by Anonymous Coward on Friday January 28 2022, @02:05AM

        by Anonymous Coward on Friday January 28 2022, @02:05AM (#1216361)

        Is it really informative if the information is wrong? 0.119 and 0.120 ARE vulnerable unless patched.

        Anyway, it's possible to backport the fix, so you might be running a distro that did that. Gentoo backported it to 0.117 which, for some reason, is the newest version supported on some non-x86 platforms.

        If you don't use pkexec, you can avoid worrying with good old-fashioned chmod 0.

  • (Score: 4, Interesting) by digitalaudiorock on Thursday January 27 2022, @07:45PM (2 children)

    by digitalaudiorock (688) on Thursday January 27 2022, @07:45PM (#1216244) Journal

    Despite what some say, it is not a systemd component (but is is a freedesktop.org project).

    Between those two it's a pretty close race as to who sucks more frankly (with the Mozilla devs arguably not far behind). Don't even get me started with the freedesktop.org project. Here's one I ran into recently:

    I use only fluxbox as a window manager. After a recent update to thunderbird I no longer had any Window decorations at all and couldn't even move the Window. Just to note: The only reason I use thunderbird for email is because I need a client that fully supports the Godless travesty that is HTML email (because of my work). If it weren't for that, I'd use a sane text only client like Claws mail. It turns out that the missing decorations issue was caused by the freedesktop.org's GTK3 "client side decorations" which they do NOT [github.com] allow you to disable, despite the fact that it breaks some window managers. With the help of another user on the gentoo forums I was able to come up with a patch that addressed this in fluxbox. I now have window decorations back...the ones that I want, and not the ones GTK3 wants.

    More importantly, you have to consider what they're doing with that whole concept of "client side decorations": You as a user choose a theme for the way you want windows to appear, any they say "fuck you..we want all GTK apps to look the same to protect our brand". And yes...although being (supposedly) part of the open source community, they very much DO use the term "brand" [wordpress.com].

    So yea, for me all three of systemd, Mozilla, and freedesktop.org pretty much epitomize everything that's wrong with Linux these day. Somehow I manage to maintain a sane, lean system despite all these a-holes.

  • (Score: 0) by Anonymous Coward on Thursday February 17 2022, @05:02PM

    by Anonymous Coward on Thursday February 17 2022, @05:02PM (#1222536)

    The difference between systemd and freedesktop is academic at this point.

    And the latter is likely a rubber stamp fig leaf for RH's control of Linux userspace by way of API churn.

    Freedesktop is supposedly about improving cross-DE compatibility on Linux. But invariably, the only "standards" that gets adopted are those proposed by people on RH payroll.

    Never mind that it was founded by RH's Gnome chief back in the day.