Two vendors, one workaround, opposite advice

Qualys disclosed PwnKit on 25 January 2022 (Qualys). Any local user can become root through pkexec, and every version since the first in May 2009 is affected. On a multi-user box that is as bad as it reads.

The advisory carries a workaround for hosts with no patch available: remove the setuid bit, chmod 0755 /usr/bin/pkexec. One command, no reboot, effective immediately.

Red Hat's bulletin answers the same question differently. Asked whether it is safe to remove the setuid bit, it says Red Hat does not recommend it, "as it will cause breakage on the system", and names Qualys's advisory while declining its advice (Red Hat). Red Hat offers a SystemTap probe instead, which has to be reloaded at every boot and does not work under Secure Boot.

Both are right, which is the problem¶

The disagreement is not about the facts. Removing the setuid bit does stop PwnKit, and it does break pkexec for everything legitimate. The two vendors are weighting those differently because they are picturing different machines.

On a headless server nobody has logged into interactively since it was provisioned, pkexec is a liability with no users. Take the bit off and the only thing that notices is the vulnerability. On an engineer's desktop, or anything running a graphical administration tool, pkexec is how software asks for privilege, and removing it breaks the machine in ways that generate tickets.

So the correct action is per host rather than per fleet, and that is a decision no advisory can make for you because neither vendor knows what your boxes are for.

What the role does with that¶

Ours is at github.com/axisops/CVE-2021-4034, MIT, and you are welcome to it. The ordering is the whole design:

• Upgrade polkit first. policykit-1 on Debian and Ubuntu, polkit on the Red Hat family. A host that can be patched gets patched and keeps a working pkexec, which means the workaround question never arises for it.
• Then compare the installed version against the distribution's fixed version, read from dpkg-query or rpm.
• Only then, and only where polkit is still unpatched, remove the setuid bit.
• Record the original mode before changing it, so --restore can put it back exactly.
• Dry run by default. Nothing changes without --apply.

The workaround is the fallback, not the fix, and the role is built so that the set of hosts receiving it is as small as the estate allows. On a fleet where everything can be patched today, the destructive path never executes.

The failure mode nobody warns you about¶

A later polkit package update restores the setuid bit.

That is the detail worth carrying away from this whole incident. If the update that restores the bit is not itself the fixed version, the host is quietly exposed again, and nothing announces it. The mitigation was correct when it was applied and is undone by routine maintenance. That is the most dangerous shape a control can have: it looks done, it is recorded as done and it is not.

The role handles it by reporting a returned setuid bit on every subsequent run and keeping the original mode it first recorded, so re-running after package updates is both safe and informative. But this workaround needs a calendar entry, not just a playbook run, until every host is patched.

What it does not do¶

Published with the code rather than found later by somebody else.

The package verdict is per host, so a pkexec outside the package, built into /usr/local/bin or shipped inside an application, is judged against the host's polkit package, whose version may say nothing about it. Red Hat's EUS and AUS streams carry their own fixed versions, but the version table is keyed on the major release only. A correctly patched EUS host is therefore reported as vulnerable and needs checking by hand against its own advisory.

The role does not deploy Red Hat's SystemTap mitigation. If you are on RHEL and you accept Red Hat's reasoning over Qualys's, this tool is not the one you want, and we would rather say that plainly than imply a coverage we do not have. It also contains no exploit code and makes no attempt to test exploitability; it reads versions and file modes and reasons about them.

The part that generalises¶

A vulnerability with a one-line workaround is not a one-line job, because the line is only correct on some of your machines.

Everything expensive about this week was classification: which hosts can be patched now, which cannot, which of those have interactive users and which will have the bit restored under them by an update three weeks from now. The chmod is instant. Knowing where to send it is the work, and an estate that can answer that from a declaration rather than a survey does this in an afternoon instead of a fortnight.