The Linux “Grinch” Vulnerability: Separating Fact From FUD

Recently, a security firm reported what they claimed to be a flaw with a major impact on organizations running Linux. (And apparently since all the rage these days is to give bugs code names, they pre-seeded the market with this timely one: “grinch”).

Linux software bugs have been huge this year, leaving administrators reeling to patch themselves from Shellshock, Heartbleed, POODLE, etc. With claims that this vulnerability could have an impact similar to Shellshock, I really wanted to dive into what the “grinch” bug means in order to separate the fact from the FUD.

Privilege escalation without credentials – By design

In their report, the firm claimed a major flaw with the PolicyKit framework in Linux. The claim was that because software leveraging this framework did not require credentials in many cases, it could lead to ‘privilege escalation’ by a malicious party with valid credentials on a system.

Think of PolicyKit as a modern-day version of setuid, or an alternative to ‘sudo nopasswd’. It is a framework that is designed to allow applications running under normal accounts to execute actions with root or administrator privileges. The idea is to improve the user experience on a desktop Linux installation (e.g., if a user needs to mount a drive, print a file, etc., they should not need to switch to administrator credentials).

In many cases, by design, it is recommended not to require authentication for such actions.

“It is not wise to require console users to authenticate for such mundane tasks as adding a printer queue (if the administrator really wants the OS to act this way, he can always deploy suitable authorization rules).”

In the ‘exploit’ example provided by this security firm, they reference a tool (pkcon) that is used to wrap package installation and makes use of PolicyKit to avoid prompting a user for credentials. The argument here is that if a user’s credentials were stolen and the package management repository contained some malicious package, pkcon could be used to install that software with no confirmation required by the user.

While this is true, this is also by design. If you are trusting users to install any software on your system without a password by using software that leverages PolicyKit, you are inherently bypassing the authentication and access control built into Linux. Red Hat confirmed this.

“Grinch” isn’t a Linux Kernel flaw, it’s an application issue

Contrary to what has been reported, this isn’t a core Linux kernel issue. It’s definitely a userland issue that is created by applications that use a framework specifically designed to circumvent authentication and access control mechanisms built into Linux.

Now, you can argue as to whether or not the access control design limitations in Linux drove application developers to frameworks like PolicyKit to improve the user experience, but it’s important to accurately scope this bug and its potential fixes.

What is true is that application developers (and to some extent, maintainers of packages in distributions) must ensure they are leveraging this framework correctly. Like programs that make use of the setuid bit to run as root, it is the responsibility of the developers and package maintainers to ensure this permission wasn’t applied incorrectly, or to vulnerable applications (e.g. software that executes user input) without understanding the security impact.

“Grinch” isn’t Shellshock 2.0

The shell /bin/bash is software that is present everywhere. This shell required massive patching efforts for nearly everyone using Linux when the Shellshock vulnerabilities emerged. In contrast, for the most part, Linux server installations (vs. desktop installations) do not generally require the use of PolicyKit-enabled software, so the impact of this bug is likely to be less pervasive.

That said, you should determine if you have PolicyKit installed, and if so, review what applications you are using on that system that leverages it to make sure they are really required.

Mitigating your exposure to “grinch”

Step 1 – Review your usage of potentially affected software

The best way to determine if you might be vulnerable is to look for software you have installed that leverages PolicyKit.

On Ubuntu Linux distributions, for example, you can run the following commands to quickly determine your risk:

dpkg -l | grep policykit # to check to see if you have policykit installed on your system

apt-cache rdepends policykit-1 # to look for any software that depends on policykit-1 that you are considering introducing into your environment.

Step 2– Use other mechanisms to elevate privileges when required

In most cases, it is possible to use other applications to accomplish the same tasks, and to do so in a way that requires credentials and not the PolicyKit framework.

For example, rather than using pkcon (the software described as ‘exploitable’), make the user `sudo` with a password prompt and a standard package manager to install software (and limit sudo execution to only necessary commands).

Conclusion

PolicyKit is working as designed, because by design it’s circumventing authentication mechanisms built into Linux for the sake of usability. That said, it’s important to be aware of the risks you are introducing and the tradeoffs of taking security shortcuts for convenience in the software you deploy on your Linux workstations and servers.

With the prolific Linux vulnerabilities in the news lately, it’s tempting to see something like this and raise alarms. However, separating the fact from the FUD helps system administrators, developers, and package maintainers make the right choices when it comes to understanding the security impact of the software on their systems.

The heart of Threat Stack's innovation and product vision, Jen is passionate about designing the next generation of security tools for our modern infrastructure. Before co-founding Threat Stack, Jen worked on Mandiant's Research and Development team under Jamie Butler, developing innovative tools to analyze malware. At Symantec, she worked on the development team architecting a backend, that processed tens of terabytes of security data every day, as well as a security analyst, in Symantec's Managed Security Services division aimed at protecting the Fortune 500 against threats.