| 4 min read
Cybersecurity researchers, much like archeologists, get to unearth ancient, sometimes terrifying stuff. This time, the huge discovery is a 12-year-old vulnerability that affects most major distributions of Linux. If exploited, this vulnerability allows any user complete control over the machine. Let's see what it's about.
Gaining root privileges with PwnKit
The cybersecurity firm Qualys' Research Team discovered the problem in the system utility Polkit, formerly called "PolicyKit." On Linux, Polkit is used for controlling privileges on the system. Further, thanks to it, non-privileged processes can communicate with privileged processes. How does this work? Polkit can execute commands with elevated privileges using the command pkexec
, followed by the intended command. pkexec
works as an alternative to sudo
, as it can be used by an authorized user to execute commands as another user.
Take a look at this description of pkexec
: "pkexec
allows an authorized user to execute PROGRAM as another user. If username is not specified, then the program will be executed as the administrative super user, root."
One may think: "Hold on! Why is this even a thing?" Well, sometimes pkexec
is used when there's some error with the sudo
command or because there are times when users need to perform an everyday action that would not be possible without root privileges. Turns out, experimenting with this command's default behavior, it was possible to exploit a vulnerability granting experimenters root privileges. The vulnerability is 12 years old but has only just been disclosed on January 25. Researchers named it "PwnKit" (see what they did there?) and assigned it the identifier CVE-2021-4034. Its severity is high with a CVSS score of 7.8.
A quite accessible description of the flaw was described by Jonathan Bennett in hacks website Hackaday.com. It goes a bit like this:
When Linux launches a program, the latter has passed two parameters: argc
and argv
. Respectively, they are the number of arguments and the list of arguments. "This information is used to parse and handle command line options inside the program." The number of arguments is always at least one, and the list of arguments will always contain the name of the binary as executed. But it's possible to launch binaries with another function, called execve()
. When using this function, the user may specify the list of arguments directly. If the list they pass to execve()
is empty, then argv
is NULL
. It turns out, pkexec
doesn't handle this well and, looking for an argument to read, ends up accessing the first environment variable, treating it as an argument and executing it as a command. This allows the user to inject uncontrolled text that can be treated as an argument to get them root privileges. Bennett explains how to do it via an error message:
pkexec
will use the gconv
shared library to print an error message, and it starts by looking for the gconv-modules
configuration file. This file defines which specific library files to open. The environment variable GCONV_PATH
can be used to specify an alternate config file, but this environment variable is blocked when running a setuid binary. Ah, but we have a way to inject an environment variable after this happens. That's the exploit. Prepare a payload.so
that contains our arbitrary code, a fake gconv-modules
file that points to the payload, and then use the NULL argv trick to inject the GCONV_PATH
environment variable. Whoami? Root.
PwnKit might not look like much if you're on a single-user system. Yet, on multi-user systems, it would allow a malicious user to bypass restrictions, escalating from no privileges to full root privileges and accessing data, making modifications, installing malware and allowing it to break havoc, and whatnot.
Who's affected? More like, who's not?
According to the director of vulnerability and threat research at Qualys, Bharat Jogi, PwnKit affects all versions of pkexec
since its first version in May 2009. A huge number of devices could be compromised, as this program is installed by default on every major Linux distribution, including Ubuntu, Debian, Fedora and CentOS. Actually, the Qualys research group verified the vulnerability, created an exploit and obtained full root privileges on those four distributions. However, in a blog post, they mentioned that other distributions may be vulnerable.
Qualys Research Team did not share their exploit code but remarked that, because of how easy it is to exploit the vulnerability, they anticipate public exploits to become available after its disclosure. And that's what happened. The very day, someone published a Proof of Concept in the wild.
Luckily, PwnKit cannot be exploited remotely. Indeed, the attacker would need to first get access to the system by a different means and, from there, start their remote attack. Another helpful bit of information is that it's possible to check for evidence of the exploitation of PwnKit as some of the exploits may leave traces in the logs. Jogi noted, though, that it's possible to exploit the vulnerability without leaving any traces.
Go get your patch!
The Qualys Research Team reported PwnKit to Red Hat Product Security on November 18, 2021, and open-source distributions project Openwall on January 11, 2022, so they could push out a patch. Shortly after, both Red Hat and Ubuntu released patches (check for versions 14.04 ESM and 16.04 ESM, and 18.04 LTS, 20.04 LTS and 21.10).
SANS Internet Storm Center handler Bojan Zdrnja advised installing the available patches, especially on multi-user systems. Also, he and Jogi suggested removing the SUID bit from the pkexec
tool as temporary mitigation if no patches are available.
As always, we at Fluid Attacks urge you to update your system with the latest patches. By the way, our own Research Team has kept busy too. Check out what we've been up to!
Recommended blog posts
You might be interested in the following related posts.
Protecting your PoS systems from cyber threats
Top seven successful cyberattacks against this industry
Challenges, threats, and best practices for retailers
Be more secure by increasing trust in your software
How it works and how it improves your security posture
Sophisticated web-based attacks and proactive measures
The importance of API security in this app-driven world