On January 25, 2022, Qualys announced the discovery of a local privilege escalation vulnerability that it identified as PwnKit. The PwnKit vulnerability affects PolicyKit’s
pkexec, a SUID-root program installed by default on many Linux distributions. The same day of the announcement, a proof of concept (PoC) exploit was built and published by the security research community. Qualys claims that this vulnerability is present on default installations of major Linux distributions such as Ubuntu, Debian, Fedora, and CentOS. According to CVETrends for the week of January 24, 2022, PwnKit has the most engagement on social media by vulnerability.
Datadog Security Research has verified this exploit using publicly available PoCs. We are releasing our analysis and coverage for Datadog Cloud Workload Security customers to help detect this exploit being used on production environments.
November 18, 2021: Qualys discovers this vulnerability and informs Red Hat of their research
January 11, 2022: Qualys sends an advisory and patch to distros@openwall
January 25, 2022: On the day of the coordinated release date, PoCs for the exploit begin circulating across code sharing sites and social media
January 25, 2022: Datadog begins investigating the vulnerability and publicly available exploits. Our security research team initiates our rapid response process to provide coverage to Datadog customers
January 25, 2022: Red Hat assigns the vulnerability (nicknamed “PwnKit”), a CVSS score of 7.8/10
Due to this vulnerability’s low barrier to entry, its widespread scope, and its default installation across many Linux distributions, it is likely that attackers will use it in order to gain a privileged foothold on production and cloud workload environments.
If PolicyKit is not installed on your operating system, you are not affected by this vulnerability. Unfortunately, PolicyKit is installed by default in most major Linux distributions except Debian.
Major Linux distributions have released dedicated security bulletins to help mitigate the vulnerability:
You can use
dpkg -s policykit-1 to see the currently installed PolicyKit version. The table below summarizes the last vulnerable PolicyKit version along with the first fixed one. Note that to patch a system running Ubuntu 14.04 LTS (Trusty) or Ubuntu 16.04 LTS (Xenial), you need to be subscribed to Canonical’s Extended Security Maintenance service, as these distributions are no longer supported.
|Ubuntu version||Latest vulnerable version||First fixed version|
|14.04 LTS (Trusty)||0.105-4ubuntu3.14.04.6||0.105-4ubuntu3.14.04.6+esm1|
|16.04 LTS (Xenial)||0.105-14.1ubuntu0.5||0.105-14.1ubuntu0.5+esm1|
|18.04 LTS (Bionic)||0.105-20||0.105-20ubuntu0.18.04.6|
|20.04 LTS (Focal)||0.105-26ubuntu1.1||0.105-26ubuntu1.2|
See Debian’s security notice here.
Contrary to other distributions, PolicyKit is not installed by default on Debian. However, it is a dependency of several popular packages, such as
firewalld. You can use
dpkg -s policykit-1 to verify the version.
|Debian version||Latest vulnerable version||First fixed version|
See Red Hat’s security notice here.
The RHEL advisory contains additional, specific mitigation measures that can be applied to CentOS/Fedora-based systems.
See AWS’s security notice here.
PolicyKit is not installed by default on Amazon Linux 2.
On most systems, updating the PolicyKit package (
policykit-1 on Debian-based systems,
polkit on CentOS/Fedora-based systems) to its latest version mitigates the vulnerability. When updating is not feasible, you can remove the SUID bit that is set by default on the PolicyKit binary,
#Remove the SUID bit on the PolicyKit binary sudo chmod -s $(which pkexec)
Several working proof-of-concept exploits and demo environments are publicly available, which likely increases potential attackers’ awareness of the vulnerability.
PolicyKit is a software that allows you to define interfaces for unprivileged processes to interact with highly privileged ones. Because of this, its executable is owned by the
root user and has the SUID bit set. This makes it an attractive target, similar to other tooling like the
The PwnKit vulnerability allows users to run the PolicyKit executable
pkexec, passing it a specific set of environment variables that cause an arbitrary library file to be loaded. As a consequence, an underprivileged attacker can invoke PolicyKit and trick it into executing an attacker-controlled
.so file on the local file system. Upon successful exploitation, the attacker is able to escalate from a user with limited privileges to a user with root access.
Datadog Cloud Workload Security monitors file and process activity in real time at the kernel level. We released the following detection rule to automatically identify exploitation attempts of the vulnerability:
(exec.file.path == "/usr/bin/pkexec" && exec.envs in [~"*SHELL*","*PATH*",”*CHARSET*”] && exec.uid != 0)
This detection monitors executions of the PolicyKit binary by underprivileged users with the environment variables
CHARSET, which are needed to trigger the vulnerability. This detection is available in Datadog today; to ensure coverage, make sure you’re using the latest Datadog Agent and have deployed the latest CWS policy.
For more information, see Workload Security Event Types.
PwnKit is a significant vulnerability because it provides attackers an easy-to-use local privilege escalation in Linux infrastructure. However, the risks and disruptions can be mitigated through a defense-in-depth security approach. Datadog customers can enable Cloud Workload Security today to get immediate defense at the runtime level by detecting the exploitation in real time. Additionally, when running workloads on Linux in production, consider minimizing the potential attack-surface by:
Only installing software that is required to run your workload.
Securing your production environment is a continuous journey, and doesn’t stop after you’ve mitigated this newest vulnerability. For a more holistic security approach, you can check out Datadog’s Cloud Security Platform and start a free 14-day trial today.
Thank you to Nick Davis, Sylvain Afchain, and Guillaume Fournier, all of whom contributed to the making of this post.