Overview

CVE-2021-4034 is a local privilege escalation vulnerability affecting the pkexec utility commonly found on Linux distributions. The vulnerability was discovered by Qualys and given the nickname of pwnkit. The vulnerability was disclosed on January 25, 2022.

Exploitation of the vulnerability allows a low privileged user to escalate to root. While there are many such vulnerabilities published every year, this one is especially interesting because exploitation is trivial, the utility is ubiquitous, and the vulnerability has reportedly existed in the software all the way back to 2009.

This is an excellent finding and a useful exploit. However, as a general reminder, an attacker that has sufficient access to exploit this vulnerability is an attacker already in your system. Remediating this issue should be on your TODO list, but things aren’t on fire here.

Exploitation

There are a number of proof of concept exploits floating around. I like arthepsy’s best, because it’s self-contained and concise. These are the two most critical lines:

char *env[] = { "pwnkit", "PATH=GCONV_PATH=.", "CHARSET=PWNKIT", "SHELL=pwnkit", NULL };
execve("/usr/bin/pkexec", (char*[]){NULL}, env);

The vulnerability is the result of how pkexec handles a NULL argument array. Above, you can see that pkexec is invoked with that exact condition. The argv[] parameter is set to NULL when calling execve. As described in Qualys’ excellent writeup, an arbitrary environment valuable can be added into pkexec’s environment if execve’s env[0]exists in the directory within the the PATH variable in env[1].

For the exploit to work in the execve above, pwnkit must exist in ./GCONV_PATH=./. Looking at the proof of concept, you can see this is configured on the very first line via a system call:

system("mkdir -p 'GCONV_PATH=.'; touch 'GCONV_PATH=./pwnkit'; chmod a+x 'GCONV_PATH=./pwnkit'");

Note that, GCONV_PATH is not the only environment variable that could be used here, but it’s the one outlined in Qualy’s writeup and works quite well. GCONV_PATH specific exploitation requires an the attacker also define a CHARSET variable. The CHARSET value can be whatever, but the attacker must make an env[0] directory that contains a gconv-modules file pointing to env[0] (which will be found via PATH). For example, the exploit we are referencing uses CHARSET=PWNKIT so it has to create this file structure:

system("mkdir -p pwnkit; echo 'module UTF-8// PWNKIT// pwnkit 2' > pwnkit/gconv-modules");

If the proof of concept used CHARSET=cheesedoodle then it would have to do this:

system("mkdir -p pwnkit; echo 'module UTF-8// cheesedoodle// pwnkit 2' > pwnkit/gconv-modules");

Note that the “cheesedoodle// pwnkit” describes the defined CHARSET and the implementing shared object. If the shared object was /tmp/pwnkit.so then this would be “cheesedoodle// /tmp/pwnkit”.

The only thing left to do is to create the shared object that pkexec will load when it attempts to print. The reference proof of concept simply writes some C code to a file and then shells out to gcc to compile it.

system("gcc pwnkit/pwnkit.c -o /tmp/pwnkit.so -shared -fPIC");

Which is fine. Not all systems will have gcc installed, but good enough. The only major thing that I need to point out about the C code is that it needs to setuid(0)/ setgid(0), otherwise it’ll be executing as the normal user.

Finally, the proof of concept also has a SHELL environment value set, but that can be set to anything invalid. For example, SHELL=a works fine. Otherwise the PoC works as advertised:

albinolobster@ubuntu:~/pwnkit$ gcc -o poc poc.c
albinolobster@ubuntu:~/pwnkit$ ./poc 
# uname -a
Linux ubuntu 5.11.0-49-generic #55-Ubuntu SMP Wed Jan 12 17:36:34 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
# whoami
root

Other notes

There has been discussion that exploits should set the GIO_USE_VFS environment variable within their exploit. I haven’t run into this myself (nor tested it), but GitHub user v-rzh explains here. The basic summary is that for some versions of pkexec the environment array will get reallocated before the attacker can write into it unless the following has been set.

setenv ("GIO_USE_VFS", "local", 1);

Useful Links

• https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt
  
• https://blog.qualys.com/vulnerabilities-threat-research/2022/01/25/pwnkit-local-privilege-escalation-vulnerability-discovered-in-polkits-pkexec-cve-2021-4034
  
• https://github.com/v-rzh/CVE-2021-4034/blob/master/README.md#whats-the-deal-with-gio_use_vfs
  
• https://linux.die.net/man/1/pkexec
  

Polkit’s pkexec binary is a bit like sudo in that it allows users to run an application as another user.
For instance, when you run something like pkexec ls you’ll be prompted for the root user’s password.
Because it allows elevated launching of programs, pkexec runs as root.

Processes that run like this are considered special and are run in a Secure-execution mode, which causes
the dynamic linker (ld.so) to strip out problematic environment variables that could introduce security
concerns. One of these “untrusted” environment variables stripped out by the linker is GCONV_PATH, which
sets the location for text conversion libraries. If a binary needs to convert a text string to a different
encoding, it will load/execute the library specified by GCONV_PATH.

For example, if we could get pkexec to run with the environment string GCONV_PATH=./exploit, pkexec would
load and execute the exploit as root if we were able to coerce the binary to use an unknown charset. This
is why the dynamic linker prevents such an environment variable from being passed into secure-execution mode
binaries.

The check to prevent GCONV_PATH environment variables is done when a program loads, so if we can modify
the environment variables after the program loads, we could add it, but as the process runs as root, we
could not change those values ourselves.

This is where the logic flaw in pkexec can be abused. pkexec runs through each argument it is passed and
calls g_find_program_in_path which takes a filename and replaces the filename with the full path to the
file, according to its PATH environment. Since there can be multiple binaries, this is done within a
loop. The specific bug in pkexec is that the loop will always run at least once, even if the number of
arguments is 0.

If the number of arguments is 0, then it will still attempt to resolve the element it pulls from memory
at the location the first argument would have been located. Because of how the stack is structured,
environment variables are located right after argument values in memory, so if there are no argument values,
then the environment values are there. The exploit works by coercing g_find_program_in_path into
writing GCONV_PATH=./exploit into the first slot in the environment list.

We can do this by creating a folder in the PATH called GCONV_PATH=. and within that folder, place a
file named abc. We also add the directory GCONV_PATH to the PATH environment variable. Now, when
we launch pkexec without any arguments, but with abc as the first environment variable and PATH=GCONV_PATH=
as the second, g_find_program_in_path will look for abc in the folder GCONV_PATH=. and find it.
It will then overwrite the first environment variable with the full path to the file as it exists in
our PATH: GCONV_PATH=./abc or exactly what we’d like to have as our environment variable.
Now, if we can coerce pkexec to use an unknown charset, it will load the library ./abc.so which we’ll make
the name of our payload.

We can coerce the loading of the .so by adding another environment variable declaring some unknown
charset: CHARSET=garbage would work fine if we could get pkexec to need to write a log. We can
get it to write a log by giving a bad value for something it depends on. In our case, we’re using
the SHELL environment variable.

So, to sum up, if we give pkexec a bad value for the SHELL environment variable and an unknown charset
to encode, it will load the .so file specified by GCONV_PATH and run it as root in an attempt to
encode to the unknown charset.

To break it down, we need to place a .so payload binary in our current working directory called
abc.so and call pkexec with no arguments and the environment values:
abc
PATH=GCONV_PATH=.
SHELL=/garbage
CHARSET=garbage

Once g_find_program_in_path runs, the environment variables will be changed to:
GCONV_PATH=./abc.so
PATH=GCONV_PATH=.
SHELL=/garbage
CHARSET=garbage

The result will be that pkexec errors while trying to encode test to the non-existant charset, causing it to
load the provided abc.so file in the root context.

This script uses your apt cache to find the current installed version of polkit and compare it to the patched version according to your distribution:

https://www.cyberark.com/resources/threat-research/checking-for-vulnerable-systems-for-cve-2021-4034-with-pwnkit-hunter