Sudo make me a sandwhich - A bug lurking for 12 years gives attackers root on every major Linux distro

[Lightwreather]

Summary

Linux users on Tuesday got a major dose of bad news—a 12-year-old vulnerability in a system tool called Polkit gives attackers unfettered root privileges on machines running any major distribution of the open source operating system.

Major Linux distributors have released patches for the vulnerability, and security professionals are strongly urging administrators to prioritize installing the patch. Those who can’t patch immediately should use the chmod 0755 /usr/bin/pkexec command to remove the SUID-bit from pkexec, which prevents it from running as a binary.

 

Quotes

Quote

Previously called PolicyKit, Polkit manages system-wide privileges in Unix-like OSes. It provides a mechanism for nonprivileged processes to safely interact with privileged processes. It also allows users to execute commands with high privileges by using a component called pkexec, followed by the command.

Since 2009, pkexec has contained a memory-corruption vulnerability that people with limited control of a vulnerable machine can exploit to escalate privileges all the way to root. Exploiting the flaw is trivial and, by some accounts, 100 percent reliable. Attackers who already have a toehold on a vulnerable machine can abuse the vulnerability to ensure a malicious payload or command runs with the highest system rights available. PwnKit, as researchers are calling the vulnerability, is also exploitable even if the Polkit daemon itself isn’t running.

PwnKit was discovered by researchers from security firm Qualys in November and was disclosed on Tuesday after being patched in most Linux distributions.

In an email, Qualys Director of Vulnerability Threat Research Bharat Jogi wrote:

Quote

The most likely attack scenario is from an internal threat where a malicious user can escalate from no privileges whatsoever to full root privileges. From an external threat perspective, if an attacker has been able to gain foothold on a system via another vulnerability or a password breach, that attacker can then escalate to full root privileges through this vulnerability.

Jogi said exploits require local authenticated access to the vulnerable machine and can't be run remotely without such authentication.

For now, Qualys isn’t releasing proof-of-concept exploit code out of concern the code will prove more of a boon to black hats than to defenders. Researchers said that it’s only a matter of time until PwnKit is exploited in the wild.

“We expect that the exploit will become public soon and that attackers will start exploiting it—this is especially dangerous for any multi-user system that allows shell access to users,” Bojan Zdrnja, a penetration tester and a handler at SANS, wrote. The researcher said he successfully recreated an exploit that worked on a machine running Ubuntu 20.04.

Major Linux distributors have released patches for the vulnerability, and security professionals are strongly urging administrators to prioritize installing the patch. Those who can’t patch immediately should use the chmod 0755 /usr/bin/pkexec command to remove the SUID-bit from pkexec, which prevents it from running as a binary.

 

My thoughts

Oh bother. As if Loj4J and a number of other cross-platform backdoors weren't enough. Well, thankfully, this is relatively lower risk as one needs to have an authenticated access to the machine (Would SSH access count toward this? 'cause if so, that makes this markedly more frightening). Thankfully, patches and work-arounds have been released and so, if you run a Linux server or PC, I do recommend you patch it.

 

Sources

Arstechnica

Qualys

Sesin

SANS

[WhitetailAni]

7 minutes ago, J-from-Nucleon said:

Would SSH access count toward this? 'cause if so, that makes this markedly more frightening

I think so; from my experience getting SSH access is basically logging into the OS as the specified user.

e.g. "authenticated access".

I wonder if iOS uses this daemon, and if so, could it be used for a jailbreak exploit?

[williamcll]

I bet there's more of these out there that's already discovered but nobody is reporting them.

[Fasterthannothing]

Good grief at this point if feels like you only have two choices of security air gap the system or just leave the thing wide open for everyone

[Sauron]

32 minutes ago, J-from-Nucleon said:

Would SSH access count toward this?

Most likely yes, although the article mentions a "local" shell. There is virtually no difference in terms of access between an SSH remote shell and a local login so I doubt it wouldn't work.

28 minutes ago, FakeKGB said:

I wonder if iOS uses this daemon, and if so, could it be used for a jailbreak exploit?

iOS is not based on Linux.

[duncannah]

That's all I need to do, right? I can't patch stuff right now

macOS doesn't have pkexec so I assume it's not affected there

[wanderingfool2]

Well at least this one is just a privilege escalation...so that's a good thing.  You'd effectively need already executable access already

[rcmaehl]

Was about to post this. Glad to see someone else is on top of things.

[Master Disaster]

3 hours ago, Sauron said:

Most likely yes, although the article mentions a "local" shell. There is virtually no difference in terms of access between an SSH remote shell and a local login so I doubt it wouldn't work.

There is as far as polkit is concerned, assuming its configured properly. SSHD will have its own rules and polkit can tell the difference between a local shell or a remote one as it knows the current TTY PID matches the PID of an app it authorised.

 

Whether this affects anything functionally, honestly can't say. I would guess that once polkit has granted authorisation it shouldn't matter what the user does to polkit, its job is finished.

 

Edit - Remember though, SSH adds an extra barrier to entry by default since a low ranking user with local access to do a job probably won't have access to an SSH TTY at all.

[Sauron]

13 hours ago, Master Disaster said:

SSHD will have its own rules and polkit can tell the difference between a local shell or a remote one as it knows the current TTY PID matches the PID of an app it authorised.

Yeah that's true, I wonder if that's enough to break the exploit.

13 hours ago, Master Disaster said:

Remember though, SSH adds an extra barrier to entry by default since a low ranking user with local access to do a job probably won't have access to an SSH TTY at all.

True, although an external attacker could social engineer you out of your password - if you're a user with high enough clearance to use SSH that's not great to begin with but it's significantly worse if you can then use the shell to gain root access. I suppose SSH adds the possibility of someone outside the premises gaining root access, so remember kids: use public key authentication and disable password logins.

[Master Disaster]

39 minutes ago, Sauron said:

 so remember kids: use public key authentication and disable password logins.

Also disable port 21, move SSH/SFTP from port 22 and move RDP from port 3389, these are the first ports any hacker will look at when trying to get in (other than 80 that is).

 

39 minutes ago, Sauron said:

Yeah that's true, I wonder if that's enough to break the exploit.

I don't think it would, polkit is used to determine rights to run and access things, AFAIK once its granted you the rights to run a shell it really doesn't care if if the shell escalates itself after the fact though its possible there's some other functionality I'm not aware of.

 

If that were a thing the polkit would break sudo su since the only people able to login as root at all would need root permissions at login, I think

[RejZoR]

Well, there goes the theory that open source is this flawless miracle and that being open ensures it's safer than "closed source" because surely someone will find and report it. If that hasn't happened for 12 years on something that causes total privilege escalation, that's a big auch.

[jagdtigger]

Compared to ms and their print spooler debacle this is nothing really....

[Master Disaster]

2 hours ago, RejZoR said:

Well, there goes the theory that open source is this flawless miracle and that being open ensures it's safer than "closed source" because surely someone will find and report it. If that hasn't happened for 12 years on something that causes total privilege escalation, that's a big auch.

False equivalency. If SUDO was closed source then this bug wouldn't have been discovered when it did and would still be possible right now.

 

Neither system is perfect, both have their benefits and disadvantages and anyone who seriously thinks OSS = less bugs doesn't understand how software works.

 

More chance of a bug being discovered =/= less bugs in the code to begin with.

[suicidalfranco]

2 hours ago, RejZoR said:

Well, there goes the theory that open source is this flawless miracle and that being open ensures it's safer than "closed source" because surely someone will find and report it. If that hasn't happened for 12 years on something that causes total privilege escalation, that's a big auch.

An exploitable bug being there for the past 12 years doesn't exclusively mean that for the past 12 year it was exploited, it means it's been written that way 12 years ago with nobody noticing it for that long

If it's been used nefariously in that period that's up for debate, but at least the moment someone discovered it got patched ASAP, unlike many closed source SW houses who rather wait for it to become news before even thinking of assigning someone to patch it.

[RejZoR]

16 minutes ago, Master Disaster said:

False equivalency. If SUDO was closed source then this bug wouldn't have been discovered when it did and would still be possible right now.

 

Neither system is perfect, both have their benefits and disadvantages and anyone who seriously thinks OSS = less bugs doesn't understand how software works.

 

More chance of a bug being discovered =/= less bugs in the code to begin with.

It's also false equivalency to assume it wouldn't be discovered if it was closed source. If it was written this way 12 years ago and being so open, one would assume someone would spot the issue by now in all this time. Yet that wasn't the case.

[Master Disaster]

8 minutes ago, RejZoR said:

It's also false equivalency to assume it wouldn't be discovered if it was closed source. If it was written this way 12 years ago and being so open, one would assume someone would spot the issue by now in all this time. Yet that wasn't the case.

Fair enough, as I said, neither system is perfect but it is true that more eyes on code means higher chance of bug being found.

 

The other consideration is the fact that people can't just view the source of closed source projects which means a lower chance of bugs being discovered at all. That's called security by obscurity and its never a good idea.

 

Edit - See EternalBlue for reference

[RejZoR]

20 minutes ago, Master Disaster said:

Fair enough, as I said, neither system is perfect but it is true that more eyes on code means higher chance of bug being found.

 

The other consideration is the fact that people can't just view the source of closed source projects which means a lower chance of bugs being discovered at all. That's called security by obscurity and its never a good idea.

 

Edit - See EternalBlue for reference

I mean, I'd believe that and while I'm aware whole OS has quite a lot of code and most of it no one looks at for years, still, it throws away the notion that just because it's open source it's magically more secure or better because more eyes "might" spot more. It affects all distros which means all the thousands of people working on Linux projects missed this for 12 years. I'm not saying Windows is inherently better either, this is just dismissing or at least placing people who overhype Linux as perfect and secure to solid ground that it's just as flawed.

 

Which is why I always say and for which I was dismissed by many in some other thread, update your software, be it Windows, Linux, Android, iOS or something else. Security updates are there for a reason and insisting on some old versions is a very bad practice.

[AnonymousGuy]

5 hours ago, RejZoR said:

I mean, I'd believe that and while I'm aware whole OS has quite a lot of code and most of it no one looks at for years, still, it throws away the notion that just because it's open source it's magically more secure or better because more eyes "might" spot more. It affects all distros which means all the thousands of people working on Linux projects missed this for 12 years. I'm not saying Windows is inherently better either, this is just dismissing or at least placing people who overhype Linux as perfect and secure to solid ground that it's just as flawed.

I can argue that open source makes it less secure because everyone thinks someone else looked at the code so they don't need to check it themselves.  And whoever wrote it in the first place may have been half drunk on the weekend and not really given a shit about it.

[jagdtigger]

37 minutes ago, AnonymousGuy said:

because everyone thinks someone else looked at the code so they don't need to check it themselves

Thats a pretty unrealistic assumption, maybe novice beginners but pros wont skip that step. It could (and usually does) bite them in the butt in the long run....

[dilpickle]

On 1/26/2022 at 11:27 AM, williamcll said:

I bet there's more of these out there that's already discovered but nobody is reporting them.

We know for a fact that government agencies know about exploits that they keep secret.

 

We're all living in a fool's paradise.

[Paul Thexton]

On 1/26/2022 at 5:11 PM, FakeKGB said:

 

I wonder if iOS uses this daemon, and if so, could it be used for a jailbreak exploit?

macOS has it’s authorisation database, and the raw configs for it (/System/Library/Security/authorization.plist) before being turned in to an SQLite database is remarkably similar to Polkit policy files the last time I compared them around 4 years ago, so I’ve always assumed there was either a branch of polkit at some point or common ancestor to both involved.

 

I can’t remember for sure if iOS has the same or similar system, I don’t do much iOS target development. 

 

As far as I understand this particular bug the flaw is in the pkexec (no real equivalent binary exists in macOS) code rather than the core of polkit, so I doubt Apple are affected if they even did use any polkit code historically.