PwnKit, or how 12-year-old code can give root to unprivileged users

It looks like IT teams have no respite. Following all the hassles caused by log4j (and its variants), there is a new high profile, high-risk vulnerability making the rounds. CVE-2021-4034, or PwnKit if you’re into fancy CVE nicknames, is a polkit vulnerability that lets unprivileged users gain root privileges on basically any Linux system out there that has polkit installed.

TuxCare’s Extended Lifecycle Support team is preparing patches for all supported distributions, and they will be available for deployment soon. This post will be updated to reflect the actual availability for each distribution as it happens.

[NOTE: Patches are now available for Centos6, Oracle6, CL6, Ubuntu16, and Centos8.4. More to follow. You can track actual distribution support through the CVE dashboard here: https://cve.tuxcare.com/cve/CVE-2021-4034.]

This vulnerability was identified by Qualys’ researchers and disclosed to distribution vendors late last year but was only made publicly available on the 25th of January, 2022.

It is extremely easy to exploit, and while the initial announcement mentioned that an exploit was likely to appear in the coming days, it actually only took around 3 hours until publicly available exploit code was discovered and confirmed as working. It affects the major Linux distributions like Ubuntu, RHEL, CentOS and their derivatives. Because the affected code was part of polkit’s initial code commit, made in 2009, it is very likely that any distribution running polkit is going to be shown vulnerable.

What is polkit (and pkexec)?

Polkit is a package that provides privilege control for managing inter-process communication when processes have different privilege levels. Through pkexec (a polkit component), this allows a user to execute commands with higher privileges than normal. For example, giving access to a specific user to perform a system-wide task without actually passing full root access to that user.

A deeper look at the vulnerability

Pkexec accepts arguments passed to it in the command line that control its behaviour (what to run, what scope, and so on). What researchers found was that it was possible to pass a null parameter and cause the code that validates the parameter to fail in such a way that memory gets corrupted with an attacker-controlled value written to the pkexec execution environment. This can then be further extended into pkexec running any command as root, and this is trivially exploitable to provide full root access to an unprivileged user.

The actual code analysis is present in Qualys’ initial announcement, linked above.

Mitigation before a patch is available

It is possible to mitigate the risk by removing SUID-bit from pkexec with the command:

Note that this will interfere with pkexec’s regular operation, so be sure to thoroughly test this change in a test environment before wide-scale adoption on your infrastructure, as it can lead to undesired side effects. Patching is still the best option.

Closing remarks

This vulnerability requires access to a system in order to be exploited, as it has no known remote attack vector. Still, it can be used by an attacker that gains access to a system to then escalate their privileges. The prevalence of polkit makes this a very serious security threat that should be patched as soon as possible to avoid undesired surprises.

This vulnerability is yet another example of a longstanding issue in open source software – just because the source is open does not mean that the right people are looking. The bug was present in 12-year-old code, and no one caught it in that time period – at least, no one publicly announced it. Fundamental projects tend to lack the resources (and incentive) to properly audit and secure their code but are disproportionately relied upon by countless other projects and distributions. To put this in perspective, a security issue in 12-year-old code is not even the “oldest” bug found in recent months. As more code gets audited, it’s likely that more flaws will be found, thus making the case for a faster pace in patching new vulnerabilities, as they emerge.

Patches for all supported distributions covered by TuxCare’s Extended Lifecycle Support service are being prepared and will be made available shortly – check back here for updates, as this post will reflect the availability of patches for the different distributions as they become ready for deployment.