Linux Bug in All Major Distros: ‘An Attacker’s Dream Come True’


The 12-year-old flaw in the sudo-like Polkit’s pkexec tool, found in all major Linux distributions, is likely to be exploited in the wild within days.


Every major Linux distribution has an easily exploited memory-corruption bug that’s been lurking for 12 years – a stunning revelation that’s likely to be followed soon by in-the-wild exploits, researchers warn.

Successful exploitation gives full root access to any unprivileged user.

The vulnerability – tracked as CVE-2021-4034, with a CVSS criticality score of 7.8 – is found in Polkit’s pkexec function. Polkit (formerly PolicyKit) provides an organized way for non-privileged processes to communicate with privileged processes, Qualys explained, and can be used to execute commands with elevated privileges using the command pkexec, followed by the command intended to be executed (with root permission).

Qualys researchers, who discovered the long-dormant powder keg and named it PwnKit, said in a Tuesday report that they developed a proof-of-concept (PoC) exploit and obtained full root privileges on default installations of CentOS, Debian, Fedora and Ubuntu. They also believe that other Linux distributions are “likely vulnerable and probably exploitable.”

Infosec Insiders Newsletter

If there’s one saving grace in this Log4j-esque, déjà vu situation, it’s that PwnKit is a local privilege-escalation vulnerability. “Any vulnerability that gives root access on a Linux system is bad. Fortunately, this vulnerability is a local exploit, which mitigates some risk,” Yaniv Bar-Dayan, CEO and co-founder at Vulcan Cyber, told Threatpost on Wednesday.

Nonetheless, PwnKit is worrying security professionals at the topmost levels: a fact underscored by a tweet from Rob Joyce, National Security Agency (NSA) director, who tweeted on Wednesday that he’s “concerned.”

Antsy Researchers Jump the Gun

A Qualys representative told Threatpost that, essentially, nobody has exploited the vulnerability in the wild – at least, not that Qualys knows about. “But the exploit was so trivial that Qualys decided not to publish it when the vulnerability was made public,” the spokesperson said on Wednesday.

However, although Qualys didn’t release its PoC, other researchers outside of Qualys “figured out and published the exploit within hours of the disclosure going live,” said the Qualys rep, pointing to a post from somebody who claimed to have recreated the exploit, executing it on an Ubuntu 20.04 system.

Others tweeted their findings, including one of Threatpost’s own Infosec Insiders, John Hammond, researcher at Huntress:


‘Dream Come True’ for Cyberattackers

“This vulnerability is an attacker’s dream come true,” Qualys researchers said on Wednesday, though “nightmare” is a better word for it when you’re sitting on the security side of things.

They offered reasons why attackers are probably misty-eyed right now:

  • pkexec has been vulnerable since its creation, in May 2009;
  • Any unprivileged local user can exploit this vulnerability to obtain full root privileges;
  • Although this vulnerability is technically a memory corruption, it is exploitable instantly, reliably, in an architecture-independent way; and
  • It’s exploitable even if the Polkit daemon itself is not running.

“This vulnerability allows any unprivileged user to gain full root privileges on a vulnerable host by exploiting this vulnerability in its default configuration,” Bharat Jogi, director of vulnerability and threat research at Qualys, said in a Wednesday post, adding that the flaw “has been hiding in plain sight for 12+ years and affects all versions of pkexec since its first version in May 2009.”

Polkit also supports non-Linux operating systems such as Solaris and *BSD, but Qualys hasn’t yet investigated their exploitability. Researchers said that OpenBSD is not exploitable, “because its kernel refuses to execve() a program if argc is 0.”

Technical Details

Qualys has provided some technical details, though as mentioned, it’s abstained from sharing its PoC before patches become widely available.

In a nutshell, an out-of-bounds write vulnerability allows for re-introduction of an “unsecure” environment variable (for example, LD_PRELOAD) into pkexec’s environment, the researchers explained.

“These ‘unsecure’ variables are normally removed (by from the environment of SUID programs before the main() function is called,” they said.

Qualys shared the following video, which demonstrates a potential exploit path.

Patch or Mitigate ASAP

It’s unclear how long it will take for distros to address the issue; but Qualys said that it expects vendors to release patches sooner rather than later. Most Linux distributions are in the process of releasing patches or have documented temporary mitigations, including Red HatDebian and Ubuntu.

Qualys also recommended that users make haste in patching as soon as those patches are available.

“Given the breadth of the attack surface for this vulnerability across both Linux and non-Linux OS, Qualys recommends that users apply patches for this vulnerability immediately,” its researchers advised.

Given the ease of exploit, Qualys also expects public exploits to become available quick-time:

“We anticipate public exploits to become available within a few days of this blog’s post date,” researchers said on Tuesday.

If there aren’t patches already available for a given operating system, there’s this mitigation: “Remove the SUID-bit from pkexec as a temporary mitigation,” Qualys suggested, giving this example:

# chmod 0755 /usr/bin/pkexec

Latest Example of the Need for SBOMs

Greg Fitzgerald, co-founder, Sevco Security, noted to Threatpost that these types of bugs – ones that have been lurking in networks for more than a decade – can create serious problems for security teams, who often don’t even know where to find all the instances of a newly problematic piece of their infrastructure.

Stop us if you’ve heard this one before, but Pkexec – just like the similarly open-source Apache Log4j logging library that’s still rocking the internet – is ubiquitous across many enterprises.

Fitzgerald said that the priority for organizations right now “has to be patching Linux machines across the enterprise.”

That is, the priority is to patch all machines that IT and security teams know about, he pointed out. Unfortunately, and this gets back to the screaming need for software bills of material (SBOMs), “there are not many companies with an accurate IT asset inventory that dates back more than a decade,” Fitzgerald understated.

Thus, even if an organization patches all of the machines they’re aware of, they could still be susceptible to the PwnKit vulnerability because they lack an accurate inventory of their IT assets, Fitzgerald said: “You can’t apply a patch to an asset you don’t know is on your network. Abandoned and unknown IT assets are often the path of least resistance for malicious actors trying to access your network or data.”

Open-Source Bugs: Good, Bad & Badder

Vulcan Cyber’s Bar-Dayan called the open-source software model a two-edged blade: “On one side, everyone can look at the code and audit it to identify and patch vulnerabilities. On the other side, threat actors can look at the code and find subtle issues that everyone else has missed,” he explained. “The advantages of this model have historically outweighed the disadvantages, with many eyes on the code and patches frequently appearing very rapidly after a vulnerability comes to light.”

He sees a future where auditing will help to catch and correct vulnerabilities before they’re used in the wild – a future that also entails improved integration with vulnerability and patch management tools that will make open-source-software-based systems even more secure and easy to maintain.

On the blade’s flip side of open-source is that there’s no one vendor holding the bag. Bud Broomhead, CEO at Viakoo, provider of automated IoT cyber-hygiene, told Threatpost that the fact that pkexec is an open-source component makes this bug “a big deal.”

After all, there’s no one vendor to blame, and no one vendor to turn to for a fix: “Unlike fully proprietary systems where a single manufacturer can issue a single patch to address a vulnerability, a single open-source vulnerability can be present in multiple systems (including proprietary ones) which then requires multiple manufacturers to separately develop, test, and distribute a patch,” Broomhead said.

That adds “enormous time and complexity” for both the manufacturer and end user when it comes to implementing a security fix for a known vulnerability, he added.

This tangled net makes open-source systems extremely attractive to threat actors. “Vulnerabilities that exploit open-source systems (like the recent Log4j vulnerability) require patches and updates to be developed by multiple device or system manufacturers, and threat actors are betting on some manufacturers being slow in releasing fixes and some end users being slow in updating their devices,” Broomhead noted.

Besides mandatory SBOMs, Broomhead said that the future has got to entail automated deployment of security fixes and extending zero trust to IoT and operational technology (OT) systems.

He ticked off the improvements that those three things would usher in: “Having clarity over what is in a software distribution via an SBOM makes finding vulnerable systems easier,” he enumerated. “Automated implementation of security fixes is needed to address the scale issue, both number and geography, especially with IoT systems. And extending zero trust to IoT/OT devices can add additional security to prevent vulnerabilities from being exploited.”

This Won’t Be the Last Horror Show

As with proprietary, so it goes with open-source: The parade of new technologies never stops. That parade ushers in new vulnerabilities and problems, as noted by John Bambenek, principal threat hunter at Netenrich.

“Compromised infrastructure is particularly useful to attackers who wish to use someone else’s resources to launch their attacks or otherwise obfuscate their identities,” Bambenek told Threatpost. “We will keep adopting new technologies in the Linux world that will introduce new vulnerabilities and problems for organizations. We are only just now getting our hands around cloud asset management, and asset management is essentially the first step of any security program.”

This article was updated at 1 p.m. ET on Jan. 26, 2022, with information about in-the-wild exploits and the lack thereof.

Check out our free upcoming live and on-demand online town halls – unique, dynamic discussions with cybersecurity experts and the Threatpost community.

Suggested articles