Is the polkit Grinch Going to Steal your Christmas?

Published: 2014-12-17
Last Updated: 2014-12-17 17:22:42 UTC
by Johannes Ullrich (Version: 1)
2 comment(s)

Alert Logic published a widely publizised blog outlining a common configuration problem with Polkit. To help with dissemination, Alert Logic named the vulnerability "Grinch" [1] .

In some ways, this isn't so much a vulnerability, as more a common overly permissive configuration of many Linux systems. It could easily be leveraged to escalate privileges beyond the intent of the polkit configuration.

Lets first step back: In the beginning, there was sudo. Sudo served the Unix community well for many decades. I had to Google this myself, but looks like sudo initially was developed in 1986 [2]. Sudo is relatively simple in its approach. A simple configuration file outlines who can run what command as what user. Of course, it isn't always as simple, as some software (e.g. many editors) allow the user to spawn shells, but for the most part administrators have found ways to fix these problems over the years. Most importantly, proper ly configured sudo requires the user to enter a password.

Polkit works differently then sudo. With sudo, I configure which software a user is allowed to run as root (or another user). With polkit, I configure which privileges a user is allowed to take advantage of while running a particular piece of software. 

The problem pointed out by Alert Logic is two fold. First of all, the default polkit configuration on many Unix systems (e.g. Ubuntu), does not require authentication. Secondly, the polkit configuration essentially just maps the "wheels" group, which is commonly used for sudo users, to the polkit "Admin". This gives users in the "wheel" group access to administrative functions, like installing packages, without having to enter a password.

The main risk is privilege escalation. With sudo, an attacker would have to enter the user's password after compromising a lesser user account in the wheel group. With polkit, all it takes is to install a package using the polkit tool "pkcon", which takes advantage of the loose polkit configuration to install packages.

What should you do? What is the risk?

First, have a relaxed christmas and enjoy it with your family. Next, take a look around your network and narrow down how is a member of the "wheel" group. Only administrators should be a member of the group ("people who change system configurations and install software for a living"). If you got some time between now and Jan 1st: Read up on Polkit and educate yourself as to what it does.

After new year: Make sure you understand how polkit action are logged, and start reviewing them. Polkit is still "new", so many system administrators don't know about it and may ignore the alerts.

Of course, Shellshock and this Polkit issue make a great 1-2 punch to get root on a Unix system. But I doubt a system still vulnerable to Shellshock has no other privilege escalation vulnerability. So I don't think it this is such a huge issue. Fix Shellshock first if that is the case.

And as always, make sure to read the original Alert Logic document to get all the details.

[1] https://www.alertlogic.com/blog/dont-let-grinch-steal-christmas/ 
[2] http://www.sudo.ws/sudo/history.html

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords:
2 comment(s)

Comments

Am I missing something? Their premise is that a user with wheel privileges has his/her account compromised. If that is the case, it is game over anyway for that Linux system. I checked the pkcon tool in both Ubuntu 14.10 and a RHEL clone (SL6.6). Both requested authentication when I tried to install a package as a user. In the case of the RHEL clone, one had to enter the root password. I don't think that pkcon is going to be a big deal on the level of shellshock. Not even close. If you want to own a system through infected binaries, a far easier way is to use Backdoor Factory or its proxy provided you can man-in-middle the victim.
"Red Hat does not consider this to be a security issue or even a bug. This is the expected behavior of the PackageKit console client."

https://access.redhat.com/articles/1298913

Diary Archives