LWN: Comments on "A new Polkit vulnerability"

A new Polkit vulnerability

xnox — Sat, 05 Feb 2022 02:30:23 +0000

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

RedDwarf — Thu, 03 Feb 2022 12:22:28 +0000

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

matthias — Thu, 27 Jan 2022 12:38:45 +0000

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

Fixing the kernel

mathstuf — Thu, 27 Jan 2022 12:35:44 +0000

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

anselm — Thu, 27 Jan 2022 11:52:47 +0000

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

rahulsundaram — Thu, 27 Jan 2022 11:16:20 +0000

> 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

tarvin — Thu, 27 Jan 2022 11:08:31 +0000

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?

Fixing the kernel

nye — Thu, 27 Jan 2022 09:54:02 +0000

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

A new Polkit vulnerability

nim-nim — Thu, 27 Jan 2022 09:09:22 +0000

> 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

jebba — Wed, 26 Jan 2022 23:42:53 +0000

Interesting old discussions about it on LWN too:

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

A new Polkit vulnerability

brunowolff — Wed, 26 Jan 2022 22:29:36 +0000

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

fenncruz — Wed, 26 Jan 2022 21:44:58 +0000

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

rahulsundaram — Wed, 26 Jan 2022 20:19:39 +0000

> 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

dmoulding — Wed, 26 Jan 2022 20:05:49 +0000

$ 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

zdzichu — Wed, 26 Jan 2022 19:36:28 +0000

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

mcatanzaro — Wed, 26 Jan 2022 19:23:58 +0000

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

mcatanzaro — Wed, 26 Jan 2022 19:13:15 +0000

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

mbunkus — Wed, 26 Jan 2022 18:21:40 +0000

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

atnot — Wed, 26 Jan 2022 18:05:36 +0000

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.

Fixing the kernel

hmh — Wed, 26 Jan 2022 17:40:30 +0000

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

A new Polkit vulnerability

dmoulding — Wed, 26 Jan 2022 17:28:15 +0000

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

zdzichu — Wed, 26 Jan 2022 16:54:26 +0000

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

A new Polkit vulnerability

yodermk — Wed, 26 Jan 2022 16:51:32 +0000

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.

Fixing the kernel

corbet — Wed, 26 Jan 2022 16:43:13 +0000

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

A new Polkit vulnerability

ballombe — Wed, 26 Jan 2022 16:16:54 +0000

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

mcatanzaro — Wed, 26 Jan 2022 15:43:46 +0000

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

jreiser — Wed, 26 Jan 2022 15:08:09 +0000

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

A new Polkit vulnerability

dbnichol — Wed, 26 Jan 2022 14:02:59 +0000

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

purslow — Wed, 26 Jan 2022 12:04:10 +0000

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

ballombe — Wed, 26 Jan 2022 09:10:45 +0000

Agreed. None of my Debian servers had it installed.

A new Polkit vulnerability

rahulsundaram — Wed, 26 Jan 2022 08:07:22 +0000

> 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

bof — Wed, 26 Jan 2022 07:19:57 +0000

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

NYKevin — Wed, 26 Jan 2022 04:52:10 +0000

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

pabs — Wed, 26 Jan 2022 04:25:34 +0000

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

bjacob — Wed, 26 Jan 2022 03:05:27 +0000

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

bjacob — Wed, 26 Jan 2022 02:49:58 +0000

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

JoeBuck — Wed, 26 Jan 2022 02:47:27 +0000

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

pabs — Wed, 26 Jan 2022 02:45:08 +0000

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

flussence — Wed, 26 Jan 2022 02:29:05 +0000

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

Smon — Tue, 25 Jan 2022 23:53:25 +0000

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`