Local privilege escalation vulnerability in polkit's pkexec
 

just stumbled onto this one.

https://isc.sans.edu/forums/diary/Lo...0214034/28272/

Yeah, I've always had a hate-hate relationship with polkit. Yet something else to get in my way ... :shrug:

I saw Redhat had patches, but haven't chased it.

AFAIR pkexec is only used to run legacy programs that aren't "polkit-aware". So if these programs were launched with gksudo or kdesudo instead there wouldn't be a problem, would there? You could deactivate pkexec altogether: take off the exec bit, not the suid bit.

Yikes! they didn't think to check for the case that no args were passed. That's "Argument Parsing 101"!

On a SUID executable that's a pretty shocking omission.


Like syg00, I've always hated the concept of polkit. It's like a really bad version of sudo over dbus with a ugly as hell XML config format: what could possibly go wrong! Wasn't expecting something this basic however.

Updated in Debian Sid.

The issue was there in Debian unstable and was fixed sometime within the past 6 days. (I had last updated the system 6 days ago and it was vulnerable when I checked). I did a dist-upgrade just now and the vulnerability has been fixed.

Slackware has patched polkit as of yesterday. :)

If you want to follow rolling out of updates in different distros, https://lwn.net/Alerts is a good place.

Indeed - I just entered "pkexec" without a command, it asks for a password, then gives me a root shell! Facepalming so hard right now.

I just tried in AntiX, which I last updated a week ago. pkexec without a command failed, giving the syntax help output. So that's all right then!

 

According to the linked blog post:
And according to another one:

But testing a not-yet-updated Debian machine, which reports pkexec as version 0.105 from 2012, it does not give a root shell (it gives the same output as --help does).

Either there is more to this vulnerability than just typing "pkexec" or the above pages are incorrect about what is affected?

it asks for password when i try it.

Arch 5.15.16-hardened

Oh yes, mine too. I think I was a little too enraged in my last post (and edited for clarity now).
However, I can imagine scenarios with keyrings where it wouldn't ask and still give global superuser access.
But TBF, most apps opened with pkexec would also do that (terminal, text editor...).
On second glance it's not a big issue as long as it still asks for the password.

The answer is that there's more to the vulnerability that just running the command; afaict, neither the --help message nor the password prompt are relevant (though perhaps the latter indicates a patched system? no idea).

Anyway, an attacker needs to create a file, then set a specific environment variable before executing pkexec, which - due to the broken argument parsing - results in it reading that file, and ultimately instructs pkexec to execute a command (e.g. /bin/sh) as root.

That's a bit vague/simplified on purpose, but a complete exploit can be done in less than a screenful of code (i.e. an attacker could potentially type it out in not much time, even if getting a file onto the system is locked down).


The fix is to upgrade polkit/pkexec to version 0.120 or higher - if for any reason you can't, you need to ensure "ls -l /usr/bin/pkexec" reports "-rwxr-xr-x" and not "-rwsr-xr-x"

If you get the latter, run "sudo chmod -s /usr/bin/pkexec" to prevent the exploit until you can get the patched version. (At which point, replace "-s" with "+s" to restore original permissions).

uh oh, i were vulnerable.
thank you for clearing this up.