A new Polkit vulnerability [LWN.net]

Qualys has announced the disclosure of a local-root vulnerability in Polkit. They are calling it "PwnKit" and have even provided a proof-of-concept video.

Successful exploitation of this vulnerability allows any unprivileged user to gain root privileges on the vulnerable host. Qualys security researchers have been able to independently verify the vulnerability, develop an exploit, and obtain full root privileges on default installations of Ubuntu, Debian, Fedora, and CentOS. Other Linux distributions are likely vulnerable and probably exploitable. This vulnerability has been hiding in plain sight for 12+ years and affects all versions of pkexec since its first version in May 2009.

Updates from distributors are already rolling out.

to post comments

A new Polkit vulnerability

Posted Jan 25, 2022 23:27 UTC (Tue) by Smon (guest, #104795) [Link] (1 responses)

Oh boy :-(
I removed suid from a lot of binaries, but sadly not pkexec.

A new Polkit vulnerability

Posted Jan 26, 2022 2:45 UTC (Wed) by pabs (subscriber, #43278) [Link]

pkexec doesn't work when it isn't setuid root, it gives this error:

pkexec must be setuid root

There was a discussion on Debian IRC about moving pkexec to a separate package from policykit, so most systems wouldn't have it installed, unless they installed a package that needed it.

A new Polkit vulnerability

Posted Jan 25, 2022 23:43 UTC (Tue) by dmoulding (subscriber, #95171) [Link] (15 responses)

From the Qualys advisory's timeline section:

> 2021-11-18: Advisory sent to secalert@redhat.

But, when I just checked, it looks like some folks at the Fedora Project are scrambling at this very moment to test the patch that they received just today. Am I understanding this correctly, that RedHat was notified of this problem more than two months ago, but nothing was done in advance to prepare a patch for Fedora?

A new Polkit vulnerability

Posted Jan 25, 2022 23:53 UTC (Tue) by Smon (guest, #104795) [Link]

It looks like the same for archlinux.
Signature Date: 2022-01-25 20:05 UTC
Last Updated: 2022-01-25 22:59 UTC (53 minutes ago)
https://archlinux.org/packages/extra/x86_64/polkit/

Fast fix is to `chmod 0755 /usr/bin/pkexec`

A new Polkit vulnerability

Posted Jan 26, 2022 15:43 UTC (Wed) by mcatanzaro (subscriber, #93033) [Link] (13 responses)

It was embargoed. We can't begin building updated packages until after the embargo is lifted. If you break the embargo by preparing an update too soon, security people get mad. ;)

A new Polkit vulnerability

Posted Jan 26, 2022 16:51 UTC (Wed) by yodermk (guest, #3803) [Link] (12 responses)

Distro security teams can't BEGIN to build packages before the embargo is lifted??? I thought the point of the embargo was to allow the packages to be ready at a coordinated time when the vuln was disclosed.

A new Polkit vulnerability

Posted Jan 26, 2022 16:54 UTC (Wed) by zdzichu (subscriber, #17118) [Link] (9 responses)

Fedora has fully open process, including what gets build in the build system and associated sources.

A new Polkit vulnerability

Posted Jan 26, 2022 17:28 UTC (Wed) by dmoulding (subscriber, #95171) [Link] (8 responses)

As far as I can tell, Fedora 35 users (don't know about other versions) still don't have a patch for this available to them. Which, again, is supposed to be, I think, the whole reason there's an embargo in the first place (so that users aren't left with unpatched systems waiting on fixes after public disclosure).

I get that the processes are open. But I guess that by definition means this is a process that doesn't accommodate the idea of security vulnerability embargoes (which by definition cannot be handled "in the open"). Seems there could be a way to be open with everything, except embargoed fixes. I'd imagine that would be exactly along the lines of what the people who came up with this convention of embargoing security vulnerability disclosure had in mind.

A new Polkit vulnerability

Posted Jan 26, 2022 18:21 UTC (Wed) by mbunkus (subscriber, #87248) [Link]

I may be totally incorrect in my assumptions, but I don't think this is actually a huge problem for Fedora users in practice, due to a combination of several reasons:

1. The problem exists in pkexec, not Polkit in general.
2. This means that attackers must be able to execute arbitrary user-level programs in order to exploit the flaw.
3. Polkit is used mostly with desktop-style systems. Desktop-style systems are usually single-user, and that user has other ways of accessing root anyway.
4. Fedora is used much more widely as desktop systems than server systems, especially not as server systems where arbitrary users can upload arbitrary code to run (e.g. web site hosting with PHP).

Of course there are most likely huge Fedora-based machine farms in several organizations (universities maybe?) where arbitrary users do have unprivileged access that I'm simply not thinking about. Anyway, there's always "rm pkexec" as a temporary workaround.

A new Polkit vulnerability

Posted Jan 26, 2022 19:23 UTC (Wed) by mcatanzaro (subscriber, #93033) [Link] (1 responses)

Normally it takes about two days to release an update for an urgent security issue, assuming the responsible packager reads bugmail regularly, notices on the first day, and no particular challenges with backporting the patch. Our infrastructure is not designed with speed as the top priority.

A new Polkit vulnerability

Posted Feb 3, 2022 12:22 UTC (Thu) by RedDwarf (guest, #89472) [Link]

Some statistics of how often an updates-testing package doesn't go to updates would help people make an informed decision here.
- Do I want "testing"? No.
- Do I want "fast"? Yes.
Since I need to compromise, I want to know how faster is fast, and how pre-tested is testing.

A new Polkit vulnerability

Posted Jan 26, 2022 19:36 UTC (Wed) by zdzichu (subscriber, #17118) [Link] (3 responses)

Your first sentence is wrong. Patched package was pushed to stable repositories at 2022-01-26 17:00:37 UTC (half hour before your comment).
It was available the testing repository since yesterday.
The package was built at 25 Jan 2022 18:11:31 UTC (https://koji.fedoraproject.org/koji/buildinfo?buildID=190...).
The code changes landed in the repo yesterday at 17:51:47 UTC (https://src.fedoraproject.org/rpms/polkit/c/a55ef1ff5db9b...)

That's for nitpicking. As for your main point – yes, Fedora openness does not align with embargoes. Only way to prepare packages earlier would be to use some shadow build infrastructure, not widely visible. That would mean losing transparency, thus losing trust which is double important for security updates.

Actually, there is another way. Commits, builds, repo composes could get metadata tag like "notVisibleBefore" set to embargo lift timestamp. Before that time, it should only show changes to the owner. But this would require really intrusive surgery in many components (starting with git). It's unfeasible.

A new Polkit vulnerability

Posted Jan 26, 2022 20:05 UTC (Wed) by dmoulding (subscriber, #95171) [Link] (1 responses)

$ sudo dnf update polkit
Fedora 35 - x86_64                               37 kB/s |  13 kB     00:00    
Fedora 35 openh264 (From Cisco) - x86_64        4.2 kB/s | 989  B     00:00    
Fedora Modular 35 - x86_64                       46 kB/s |  13 kB     00:00    
Fedora 35 - x86_64 - Updates                     35 kB/s |  10 kB     00:00    
Fedora 35 - x86_64 - Updates                    504 kB/s | 447 kB     00:00    
Fedora Modular 35 - x86_64 - Updates             45 kB/s |  13 kB     00:00    
Dependencies resolved.
Nothing to do.
Complete!

I just did that. So still no update available to me on this system. Not sure why if the patched build was available already.

But as to the feasibility, why is it infeasible to have closed infrastructure on which to make commits, do builds and test? Then when an embargo is lifted, the commits can be pushed to the public repo, builds done and released immediately, without having to wait for testing. Doesn't on the surface seem infeasible to me, but admittedly I'm not a developer for any distro (let alone Fedora) so I don't know what nuances would make this impractical.

A new Polkit vulnerability

Posted Jan 26, 2022 20:19 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

> I just did that. So still no update available to me on this system. Not sure why if the patched build was available already.

The patched builds are available in updates-testing repo. The commits go into a spec + patches repo in https://src.fedoraproject.org/ and then the builds happen via https://koji.fedoraproject.org/koji/

Once the builds are available there, Bodhi is used to push the updates to updates-testing for public comments and testing via https://bodhi.fedoraproject.org/

In this case, for Fedora 35, this is the errata

https://bodhi.fedoraproject.org/updates/FEDORA-2022-da040...

dnf install <foo> --enablerepo=updates-testing

> But as to the feasibility, why is it infeasible to have closed infrastructure on which to make commits, do builds and test?

It isn't infeasible but it is considerable amount of work to duplicate a good amount of the infrastructure somewhere privately, find the resources to test it privately and push it out slightly earlier while still allowing community volunteers to participate.

A new Polkit vulnerability

Posted Jan 26, 2022 22:29 UTC (Wed) by brunowolff (guest, #71160) [Link]

There is more to it than just getting pushed to stable for naive users. (People who know can get the build directly from koji. But you need to know you want the update.)
Composes of repos typically happens once a day with the set of packages in stable at around 0500 UTC. Typically the compose finishes 8 to 10 hours later and gets copied to the primary source for distribution. Before most people see the change, it needs to be copied to the mirror they use. I think some pick them up pretty quickly, but others might only check once a day.

If you happen to be using rawhide right now, composes have been failing more than usual the last week, including the last two days. If this threat is a high priority for you (e.g. if you have multiple users on your system that you don't fully trust to behave), then you need to pull a copy from koji or from this morning's failed compose (which will have a lot of updates).

A new Polkit vulnerability

Posted Jan 27, 2022 9:09 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

> I get that the processes are open. But I guess that by definition means this is a process that doesn't accommodate the idea of security vulnerability embargoes

Embargoes are predicated on the idea components are independant and you can prepare an update in a sekret top security facility isolated from everything else.

In reality modern components are deeply interdependant, moving one part echoes far and wide, and requires notifying lots of people (see: log4j).

A new Polkit vulnerability

Posted Jan 26, 2022 19:13 UTC (Wed) by mcatanzaro (subscriber, #93033) [Link] (1 responses)

Well packagers can of course prepare things locally in advance, but if you make public commits or use public build infrastructure, then you've broken the embargo. So yeah, the actual process of building the update cannot begin until after the embargo has ended.

Distros with private infrastructure (e.g. RHEL) are able to prepare more easily.

A new Polkit vulnerability

Posted Feb 5, 2022 2:30 UTC (Sat) by xnox (subscriber, #63320) [Link]

I don't see how being open prevents to be integrated with embargoes. Ubuntu uses Launchpad, which supports private builds, but also converting private builds to public. It allows building update privately, and publishing them publically which at publication time reveals source code and full build-logs.

If there were enough resources committed, surely koji / fedora could implement the same. Push private tags, do builds, and unembargo them at publication time. A missing build infrastructure feature, and lack of timely security support. Not really anything to do with "openness".

A new Polkit vulnerability

Posted Jan 26, 2022 2:29 UTC (Wed) by flussence (guest, #85566) [Link] (11 responses)

If I'm reading this right, the exploit is putting garbage in execve(2) and the kernel isn't doing any checking or rejecting of it, instead passing those values straight through to a (setuid) program that isn't expecting the kernel to give it a bunch of nonsense.

As much as I'd like to rag on polkit for being a pile of "so complex there are no obvious deficiencies" software running as root, this actually looks like a kernel bug. There may be other software affected by this that we're not aware of yet.

A new Polkit vulnerability

Posted Jan 26, 2022 2:47 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] (1 responses)

Seems there's a one-line no-risk fix; in main, if argc is 0, exit with error immediately. Right? Am I missing something?

A new Polkit vulnerability

Posted Jan 26, 2022 18:05 UTC (Wed) by atnot (guest, #124910) [Link]

There appears to be a lot of hastily written code in the wild that just sets argc/argv to NULL because it happened to work so far.

A new Polkit vulnerability

Posted Jan 26, 2022 2:49 UTC (Wed) by bjacob (guest, #58566) [Link] (2 responses)

I would like to hear a definitive comment on this. From the Qualys article, the specific kind of 'garbage' that is being passed by the kernel, by means of execve, to the executed program, is that argc==0 and argv[0]==NULL. Is that garbage or something that I should be prepared to handle in programs that I write? Is there some specification (POSIX??) governing that?

A new Polkit vulnerability

Posted Jan 26, 2022 3:05 UTC (Wed) by bjacob (guest, #58566) [Link] (1 responses)

Self-reply - looks like this has been answered already on SO:
https://stackoverflow.com/questions/49817316/can-argc-be-...
So argc can really be 0, and the standard saying so is the ISO C language standard.
So this isn't a Linux bug but I think flussence's meta point stands: there are probably many other programs that didn't know that they had to be ready for argc==0, so this is is surprising, and surprising is insecure... so it might still be a good idea for the kernel to step in to ensure argc>=1 and argv[0]!=NULL even though this isn't the kernel's fault. I'd be really curious though if there are legitimate usage patterns that would be broken by doing so..

A new Polkit vulnerability

Posted Jan 26, 2022 4:52 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

That depends what the kernel does in response to this. If for example it sets argc to 1 and puts an empty string in argv[0] (and puts NULL in argv[1]), then I would be very surprised if any program cared.

OTOH, there might be (read: I could imagine) some programs that fork-exec a helper program with NULL argv[0] just because it's easier than passing the correct arguments, so if the kernel returns -EINVAL or something, those programs might break.

A new Polkit vulnerability

Posted Jan 26, 2022 4:25 UTC (Wed) by pabs (subscriber, #43278) [Link]

From the advisory:

Last-minute note: polkit also supports non-Linux operating systems such
as Solaris and *BSD, but we have not investigated their exploitability;
however, we note that OpenBSD is not exploitable, because its kernel
refuses to execve() a program if argc is 0.

A new Polkit vulnerability

Posted Jan 26, 2022 15:08 UTC (Wed) by jreiser (subscriber, #11027) [Link]

The Linux kernel definitely is NOT at fault. (0 == argv[0]) is perfectly legal in the second argument to execve(), even for a file with the setuid bit set. Any bugs or surprises are the fault of the file named as the first argument to execve().

Fixing the kernel

Posted Jan 26, 2022 16:43 UTC (Wed) by corbet (editor, #1) [Link] (3 responses)

For the curious, requiring argc>=1 is currently under discussion on linux-kernel.

Fixing the kernel

Posted Jan 26, 2022 17:40 UTC (Wed) by hmh (subscriber, #3838) [Link] (2 responses)

https://lwn.net/ml/linux-kernel/20220126114447.25776-1-ar... as well.

Fixing the kernel

Posted Jan 27, 2022 9:54 UTC (Thu) by nye (guest, #51576) [Link] (1 responses)

And (perhaps) finally: https://lwn.net/ml/linux-kernel/20220127000724.15106-1-ar...

Fixing the kernel

Posted Jan 27, 2022 12:35 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Hmm, that `pr_warn_once` seems odd. I'll get a warning for the first time something tries this, but nothing on subsequent attempts?

A new Polkit vulnerability

Posted Jan 26, 2022 7:19 UTC (Wed) by bof (subscriber, #110741) [Link] (5 responses)

I uninstall polkit (actually, replace it with a higher version empty package) in prod.

What would I miss, on servers / vms? I never consciously used it for sure, sudo does everything I need.

A new Polkit vulnerability

Posted Jan 26, 2022 8:07 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

> What would I miss, on servers / vms? I never consciously used it for sure, sudo does everything I need.

It's largely used on desktops, so probably nothing.

A new Polkit vulnerability

Posted Jan 26, 2022 9:10 UTC (Wed) by ballombe (subscriber, #9523) [Link]

Agreed. None of my Debian servers had it installed.

A new Polkit vulnerability

Posted Jan 26, 2022 12:04 UTC (Wed) by purslow (guest, #8716) [Link]

In my Gentoo system, it's required by KDE :

emerge -cpv polkit
Calculating dependencies... done!
sys-auth/polkit-0.120-r1 pulled in by:
gnome-extra/polkit-gnome-0.105-r2 requires >=sys-auth/polkit-0.102
sys-auth/polkit-pkla-compat-0.1 requires >=sys-auth/polkit-0.110
sys-auth/polkit-qt-0.114.0 requires >=sys-auth/polkit-0.103
sys-fs/udisks-2.9.4 requires >=sys-auth/polkit-0.114

A new Polkit vulnerability

Posted Jan 26, 2022 14:02 UTC (Wed) by dbnichol (subscriber, #39622) [Link] (1 responses)

Using systemd unprivileged as it uses polkit for authorization. But if you're always using sudo to gain privilege then probably nothing.

A new Polkit vulnerability

Posted Jan 26, 2022 16:16 UTC (Wed) by ballombe (subscriber, #9523) [Link]

...and if you use sudo, and your account is compromised, it is just a matter of waiting for you to use sudo to get root.

A new Polkit vulnerability

Posted Jan 26, 2022 21:44 UTC (Wed) by fenncruz (subscriber, #81417) [Link] (1 responses)

Apparently this was found 9 years ago ( https://mobile.twitter.com/ryiron/status/1486207182404472...) on this blog https://ryiron.wordpress.com/2013/12/16/argv-silliness/

A new Polkit vulnerability

Posted Jan 26, 2022 23:42 UTC (Wed) by jebba (guest, #4439) [Link]

Interesting old discussions about it on LWN too:

https://lwn.net/Articles/342330/

A new Polkit vulnerability

Posted Jan 27, 2022 11:08 UTC (Thu) by tarvin (guest, #4412) [Link] (3 responses)

On a typical RHEL/CentOS server, I claim that polkit is not being used, but it seems it cannot be removed, because NetworkManager depends on it. Even though NetworkManager can also be removed from some servers, one cannot have that as a general assumption.

So it appears one cannot have a general policy for removing polkit, even though that would be nice (I fear more surprises like this could be waiting to pop up for polkit.)
But maybe some hardening can happen, still.

My question:
Does someone know if stopping the polkit service will prevent bugs like this from being exploitable?

A new Polkit vulnerability

Posted Jan 27, 2022 11:16 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

> Does someone know if stopping the polkit service will prevent bugs like this from being exploitable?

Removing suid bit is suggested as a mitigation step for this vulnerability. That should help in general. Alternatively, locally generate an RPM with pkexec as a subpackage and just don't install it for your servers. There is a fedora devel list discussion about doing that upstream but it will likely take a while to trickle down even if they do that.

A new Polkit vulnerability

Posted Jan 27, 2022 11:52 UTC (Thu) by anselm (subscriber, #2796) [Link]

Does someone know if stopping the polkit service will prevent bugs like this from being exploitable?

The polkit service as such has nothing to do with the bug. It is a problem with the way the pkexec executable deals with command line arguments, or more specifically the absence of command line arguments, combined with the fact that it is set-UID root. The exploit doesn't rely on polkit in particular at all.

A new Polkit vulnerability

Posted Jan 27, 2022 12:38 UTC (Thu) by matthias (subscriber, #94967) [Link]

> Does someone know if stopping the polkit service will prevent bugs like this from being exploitable?

As long as the pkexec executable is available with the SUID bit in place, this is trivially exploitable. The executable itself is the problem.