Major Linux PolicyKit Security Vulnerability Uncovered: Pwnkit (zdnet.com) 179
An anonymous reader quotes a report from ZDNet: [S]ecurity company Qualys has uncovered a truly dangerous memory corruption vulnerability in polkit's pkexec, CVE-2021-4034. Polkit, formerly known as PolicyKit, is a systemd SUID-root program. It's installed by default in every major Linux distribution. This vulnerability is easy to exploit. And, with it, any ordinary user can gain full root privileges on a vulnerable computer by exploiting this vulnerability in its default configuration. As Qualsys wrote in its brief description of the problem: "This vulnerability is an attacker's dream come true." Why is it so bad? Let us count the ways:
- Pkexec is installed by default on all major Linux distributions.
- Qualsys has exploited Ubuntu, Debian, Fedora, and CentOS in their tests, and they're sure other distributions are also exploitable.
- Pkexec has been vulnerable since its creation in May 2009 (commit c8c3d83, "Add a pkexec(1) command").
- An unprivileged local user can exploit this vulnerability to get full root privileges.
- Although this vulnerability is technically a memory corruption, it is exploitable instantly and reliably in an architecture-independent way.
- And, last but not least, it's exploitable even if the polkit daemon itself is not running.
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. It's recommended that you obtain and apply a patch ASAP to protect yourself from this vulnerability.
"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."
- Pkexec is installed by default on all major Linux distributions.
- Qualsys has exploited Ubuntu, Debian, Fedora, and CentOS in their tests, and they're sure other distributions are also exploitable.
- Pkexec has been vulnerable since its creation in May 2009 (commit c8c3d83, "Add a pkexec(1) command").
- An unprivileged local user can exploit this vulnerability to get full root privileges.
- Although this vulnerability is technically a memory corruption, it is exploitable instantly and reliably in an architecture-independent way.
- And, last but not least, it's exploitable even if the polkit daemon itself is not running.
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. It's recommended that you obtain and apply a patch ASAP to protect yourself from this vulnerability.
"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."
Typo or intential flame-bait? (Score:3, Informative)
Polkit, formerly known as PolicyKit, is a systemd [emphasis mine] SUID-root program.
PolicyKit is not part of or related to systemd - it pre-dates systemd's existence.
Re: (Score:3, Funny)
Re:Typo or intential flame-bait? (Score:5, Informative)
Not true. It typically depends on libsystemd0 and gets installed with systemd: https://packages.debian.org/bu... [debian.org]
It may be possible to install it without a systemd installation, but that will at least be difficult.
Basically if you install systemd you also get policykit and are vulnerable. If you use a sane init-system, you do not have policykit.
Some minimal fact-checking ability required to comment competently.
Re: (Score:3)
Alas, elogind (ie, pieces of systemd extracted for use with sane init systems) includes bits needed for policykit, to let modern desktop environments run unmodified. Thus, using a sane init doesn't imply you're safe here.
Re: (Score:3)
At least on Debian, pkexec is not in elogind. But there is a recommended dependency on policykit-1 and that depends on libsystemd0.
Seems this crap can creep in in other ways too.
Re:Typo or intential flame-bait? (Score:5, Insightful)
It didn't "creep in". It's been deliberate by Lennart Pottering and his fans for the last decade to replace as much of the system core tools as possible, believing that a monolithic and Linux-only set of tools can replace decades of UNIX developments. Some of the architectural debacles have been fairly predictable, others were not specifically predicted but their class of errors is not surprising.
Re: (Score:2)
Some of the architectural debacles have been fairly predictable
The architectural debacles may be predictable but completely unrelated to systemd. Policykit only depends on systemd since systemd introduced functionality that it was previously providing.
You want the year of Linux on desktop? It needs to act as a desktop OS. That includes providing functionality that users expect, functionality such as what policy kit provides. Now as to how these applications hook into the underlying system you can either use another library (what a fucking foreign concept in Linux amiri
Re:Typo or intential flame-bait? (Score:5, Funny)
There's simple, well defined use of modular libraries and then there's kitchen sink dependency. Next thing you know, excessive use of the windshield washer deflates your spare tire.
Re: (Score:3)
Some have been quite predictable, other failures were quite the surprise. The binary-only logging system are one set, rather than text based logging system compatible with existing log analysis tools were one class and introduced issues with Unicode output as well. The creeping expansion into logind functionality, especially the unexpected, unrecorded, and unwelcome termination of background processes, was another. Interweaving systemd with Polkit, which used to be more modular, makes patching it more dange
Re:Typo or intential flame-bait? (Score:5, Interesting)
Systemd has proprietized Linux, making core functionality completely incompatible and non-portable to other operating systems. The ongoing proprietization of Linux has been severe.
What do you expect when you have a for profit company with lots of influence on some core parts of the OS? They try to extend that influence more and more to de facto control the OS.
Redhat/IBM has slowly taken over nearly every critical part of GNU/Linux (often by beating out canonical who was also trying): sound, display server, init, networking, logging, login, DE (gnome is still the default DE on most big distribs), package management (flatpak is thankfully facing resistance though) etc.
Systemd is their crown jewel through which they can slowly replace every core GNU utility one by one. Their wet dream has to be taking over the kernel.
We are playing a very dangerous game of putting all our eggs in the same basket. A basket held by a for profit company that has proven to be untrustworthy (remember CentOS) and that has entirely different goals from us (by definition, they have only one goal: make more money for their shareholders, even if that would mean burning gnu/linux to the ground).
Re: (Score:2)
It is not (yet) that bad actually. I run Debian without systemd and Gentoo without systemd. Both work pretty well. If something requires systemd or its components, I simply regard that as not being part of Linux anymore and do without it.
I do agree on the general idea behind systemd though: Make Linux like Windows, remove as much user-choice as possible.
Re: (Score:2)
Well, that was wordplay because as developer I consider Poettering a "creep". Probably too subtle, my apologies.
Fully agree on the rest. Poettering obviously has "kernel envy" and wants to ideally wrap the kernel so everybody has to use his crap.
Re:Typo or intential flame-bait? (Score:5, Insightful)
It is not monolithic, it is entirely modular.
It's monolithic like the Linux kernel is monolithic. Sure it has "modules", but that's irrelevant for the discussion.
The modules are not seperable, and depend on each other. Once you have module A depending on module B, then in order to use A in systemD, B is carried along. Well B will do something to the system/provide some service which isn't JUST used by systemd. Now using a nonsystemD thing for B is much harder if you want systemd's A.
I think part of the hate for systemd is it's proponents often misprepresent what it is. There are advantages to tighter integration, but let's not pretend that tight integration doesn't in fact have tight integration.
Re: (Score:2)
I think part of the hate for systemd is it's proponents often misprepresent what it is. There are advantages to tighter integration, but let's not pretend that tight integration doesn't in fact have tight integration.
THIS!
If you claim your silver bullet supports feature A when it clearly does not, I will naturally distrust your silver bullet and everything you say about it, and wonder what your hidden motives are. The more sophistry you throw at me trying to cram your square peg into a round hole, the deeper the distrust gets.
Re: (Score:2)
No it is not. most of it can be installed independently of each other. That is how it has been making inroads, one optional service at a time. The only thing monolithic is the source repository, it modular in installation and functionality, more so than the linux kernel.
Re: (Score:3)
Modularity implies interchangeabilily. A => B => A without (non-trivial) loss of functionality.
Now, are you for real claiming you can easily move from systemd to initv modules? Cause in that case I got a bridge to sell ya!
Re: (Score:2)
It's monolithic like the Linux kernel is monolithic. Sure it has "modules", but that's irrelevant for the discussion.
No.
It does not have "modules", systemd is made out of 60+ binaries (last I checked). Each one is a separate application and runs in a separate process isolated from each other. Modules in the kernel are loaded in the kernel's space. Modules are more like dynamic libraries for the kernel.
Systemd is more like util-linux or binutils, it is just a collection of many small applications that happen to be shipped together and that work well together. Most of those applications do not depend on each other but w
Re:Typo or intential flame-bait? (Score:5, Insightful)
Yes. It's split into different binaries. These binaries are still intertwined. That's like claiming a rope isn't a rope just because it's made of smaller individual threads.
Each and every utility in SystemV can stand on it's own. Try running any systemd utility without systemd core running, yeah, not happening...
Re: (Score:2)
I think part of the hate for systemd is it's proponents often misprepresent what it is. There are advantages to tighter integration, but let's not pretend that tight integration doesn't in fact have tight integration.
I agree. The constant lying by the systemd-cult means you cannot trust a single thing they claim.
Re: (Score:2)
But it is not inter-operable (which most people consider part of "modular"). By your definition, everything is modular. My car is "modular" because I can replace the fuel pump with an identical fuel pump.
To be really modular, I should be able to use SysV's /sbin/init and have it invoke systemd from /etc/inittab or even from a script in /etc/rcS.d. SPOILER: I cannot.
Re: (Score:2)
Of course it is interoperable. How do you THINK it has been installed piecemeal into distros? Not working right for years until a new part was added. It has always worked with the old systems.
Re: (Score:2)
Re: (Score:3)
If systemD is just a replacement for /sbin/init, then why does it include resolved at all? That's not it's job! Why does resolvd give a crap what is running for initializing the system, that's above it's pay grade. The answer is that the whole fuzzball is not actually modular at all.
Meanwhile, In order to avoid having network connections just *POOF* from time to time, I remove both NetworkManager AND Netplan from the system. Both are solutions looking for a problem anyway.
Re: (Score:2)
It is not monolithic, it is entirely modular.
Nope. And at this time this does not need any justification or explanation anymore. You are either clueless or lying.
Re: (Score:2)
libsystemd0 is very hard to be avoided in Debian, at least if the user wants to run Gnome. A large number of other packages depend indirectly on libsystemd0 too. I'm running elogind myself, but I can't get rid of libsystemd0 if I want to have a semblance of an useful system. Still, elogind + libsystemd0 is the way lesser evil than the full systemd, thank God.
Re: (Score:2)
libsystemd0 is very hard to be avoided in Debian, at least if the user wants to run Gnome. A large number of other packages depend indirectly on libsystemd0 too. I'm running elogind myself, but I can't get rid of libsystemd0 if I want to have a semblance of an useful system. Still, elogind + libsystemd0 is the way lesser evil than the full systemd, thank God.
Why would I ever want to run Gnome? I looked at it way back and found my FVWM setup was way better.
But yes, you have a point. I still wonder whether Gnome got actively corrupted by Red Hat or whether they did this stupid thing all by themselves.
Re: (Score:2)
Here's an anecdotal data point: I just read the article on my pclinuxos system, which does not use systemd. I did a 'which pkexec', and, lo and behold, there it was in /usr/bin. I'll check my devuan system next time I fire it up.
Re: (Score:2)
Here's an anecdotal data point: I just read the article on my pclinuxos system, which does not use systemd. I did a 'which pkexec', and, lo and behold, there it was in /usr/bin. I'll check my devuan system next time I fire it up.
Maybe you got infected via elogind as somebody else pointed out.
Devuan should not have libsystem0 and hence no policykit with pkexec. But if would be good to get confirmation on that. I tried finding pkexec via the devuan website packet search and it seems it is not present. I am not 100% confident on that though.
Re: (Score:2)
I did 'which pkexec' on my devuan system and it was there.
Hmm. Interesting.
Re: (Score:2)
Here's another anecdotal data point: I just checked on a Debian Squeeze system I (still) have running here, which according to my notes was "installed from AMD64 netinst.iso 6.0.4 on 12/03/2012".
systemd first appeared in Debian Jessie (8.0) in 2015.
Re:Typo or intential flame-bait? (Score:5, Informative)
Not true. It typically depends on libsystemd0 and gets installed with systemd
Yes true. It depends on systemd *NOW*. That doesn't change the fact that it is not part of systemd, predates systemd, was not developed by people working on systemd, and was installed by default on distributions before systemd was even introduced.
Basically if you install systemd you also get policykit and are vulnerable
And? That doesn't make it a systemd component. If you install any Debian based OS, even ones predating the systemd move, and even Devuan the specifically anti-systemd distribution you get policykit, just in the case of Devuan they use a shim instead of libsystemd0.
Some minimal fact-checking ability required to comment competently.
Fuck me man. If I posted as much garbage as you did I would die of shame if I were also such a smartass.
Re: (Score:2)
It depends on systemd *NOW*
It depends on libsystemd0, at least in recent Debian versions. Are you saying that systemd and libsystemd0 are the same thing? Isn't libsystemd0 just a tiny part of systemd?
Re: (Score:2)
Re: (Score:2)
On my system, pkexec is linked against over two dozen shared libraries - that doesn't make it a part of glibc or PCRE or any of the others. The fact that PolKit can integrate with systemd does not make it a part of systemd.
You should try some fact-checking - the summary says this bug dates back to 2009, which is before systemd was even released.
Re: (Score:2)
Slackware current uses sysV but also installs policykit.
Glass houses, and all that?
At last... (Score:5, Funny)
Re:At last... (Score:5, Informative)
Ah, no. Unlike the log4j disaster, this is a patch in one place per system and that is it. The main problem with log4j is finding where it was put in.
Well, it looks like yet again... (Score:2)
C string and array manipulation FTW.
Re: (Score:2)
On the bright side 13,000 eyeballs* were on the job and caught this quickly. Truely a win for open source over proprietary.
*(13 years * 1,000 eyeballs)
Re: (Score:2)
I'm pretty surprised this took so long to get out. (notice I don't say find, because a found vuln that's not out is a 0day, conceivable someone secretly exploiting that never got caught with the exploit method.) I thought there were people fuzzing suid binaries like crazy that would have found this long ago. I mean user input to setuid binaries is like the second set of stuff to look at when trying to come up with a new zero day. (remote input to elevated privs binaries being the first, of course)
However to
Re: (Score:2)
Much more likely that a closed source bug like this would be found by a black hat.
And that is the point. Sure, there is stupid code in Linux distros and some of it in core functionality. I advise the interested reader to have a look at the "fixed" source code of pkexec for a good example how to _not_ do things. But the thing is that such a vulnerability will stay non-public far longer on closed source and, in addition, when it gets discovered on open source you can directly verify what is going on while on closed source you can just trust the vendor. For policykit, after a look at the so
Re: (Score:2)
> will stay non-public far longer on closed source a
Given the people who can, and do, have developer licenses to source code, or who can steal it, there is no guarantee of this. Obfuscating the source code, for example by weaving it into systemd, takes eyes away from seeing it.
Re: (Score:2)
I meant "non-public" = "only known to attackers" and it is a tendency not an assurance.
Fully agree on Systemd though. Nobody sane and competent will waste time on that of their own free will.
Re: (Score:2)
Worth being said, if you are writing C code, make sure you use an alternate string library (or have some other method to avoid these kinds of bugs).
Re:Well, it looks like yet again... (Score:5, Informative)
Actually, that would not have helped here. Basically, due to abysmal stupidity, this code writes argv[1] without ever checking that argc is larger than 1. Somebody clearly tried to write clever code and failed. In a suid-binary, no less.
Re: (Score:2)
That's remarkably bad. I didn't know argv was guaranteed to be mutable.
And this code from someone who claims to understand unix.
Re: (Score:2)
Indeed. "remarkably bad" captures it nicely.
No surprise (Score:2)
This is just the kind of high quality work I expect IBM to do.
Re: (Score:2)
Still Red Hat only in 2009 but the same principle applies.
Re: (Score:3)
You don't have to look at systemd code for very long to realize it wasn't written by highly skilled programmers who know how to organize code.
Re: (Score:2)
Indeed. And I just looked at the current "fixed" pkexec code. These people are not any better.
Re: (Score:2)
Re: (Score:2)
Same people, right?
Re:No surprise (Score:4, Informative)
Re: (Score:2)
I would not be surprised at all if the development of polkit is as old as the module system in Linux.
It's not. The first commit was in 2006.
Details, details... (Score:4, Informative)
For one, I am glad I do not run a "major" linux distribution (Slackware).
From Qualys article (full of a hard sell for their security product), and left out of the ZDNet article:
"Is this vulnerability remotely exploitable?
No. But if an attacker can log in as any unprivileged user, the vulnerability can be quickly exploited to gain root privileges."
*yawn*
Re: (Score:2, Interesting)
Re: (Score:2)
yes, Slackware does come with it, and it is in Current.
But, Slackware has a lot of things that may or may not get used. I strongly suspect polkit is only used when someone wants to use KDE (and maybe xfce4) in Slackware. If on a regular WM like I use, I doubt it is used. I will play around to see.
In anycase Slackware released a patch for it yesterday.
Not systemd, but part of the same crap-show (Score:5, Informative)
Basically, if you use systemd, you typically also use policykit and are vulnerable. If you do not use systemd but a sane init-system, you generally do not have policykit and are not vulnerable to this. There may be a way to install poicykit without systemd, but it depends, for example, on libsystemd0, so it would require at least a partial systemd installation to work.
The cancer that came over to Linux from the Windows-minded and incompetents with big egos is not limited to core systemd.
I stay far away from systemd and I have nothing to patch here on any of my installations using several different distros. The only instance of pkexec I have is from an old backup of an orange-pi zero installation before I nuked systemd on it.
Re: (Score:3, Informative)
The PolicyKit software is named "polkit" on Red Hat based systems, including Amazon Linux. Its incestuous interlacing with systemd is Lennart Pottering's fault: he used to write pulseaudio, which relies on it, and he *loves, loves, loves* to violate basic security and performance practices like "not breaking other people's working software" in favor of his Tower of Systemd Babylon approach to the operating system stack.
Re: (Score:3)
Re: (Score:3, Insightful)
If you do not use systemd but a sane init-system, you generally do not have policykit and are not vulnerable to this.
Stop being such an ignorant idiot. Policykit was a default component of distributions regardless of init system, it was a default component of RedHat and Debian before the introduction of systemd, and it's also included by default in anti-systemd distributions such as Devuan.
But you made an anti-systemd comment so I guess we should shower you with modpoints.
Re: (Score:3, Informative)
Re: (Score:2)
If I had mod points you'd get 'em!
Thanks! The sentiment is appreciated.
Everything I've seen in systemd is inelegant.
Indeed. And then you realize it runs as PID 0 where elegance, robustness, clarity and KISS could not be more critical. The people behind this mess simply do not have what it takes.
I have been tempted to move my servers off Linux and to FreeBSD several times because of the systemd mess. Currently, there are still good Linux distros, but the mainstream is slowly getting worse.
Re: (Score:2)
I have quite a bit of my workload on FreeBSD. I will say that ZFS is also a huge draw. Linux can do ZFS but it isn't as performant as it is on FreeBSD. And ZFS is so worth it.
At some point fairly recently, some update on one of my small experimental Linux ZFS pools has started causing any process that touches the ZFS (and perhaps even some that don't touch it but stat its mountpoint) to hang for several seconds. I've been meaning to try ZFS on FreeBSD, maybe now's the time...
As for systemd, it does the thing it's meant to do (make Linux "just work" the way Windows "just works") pretty well. It makes Linux a lot more "desktop ready," in that random users can download a Linux im
Re:Not systemd, but part of the same crap-show (Score:4, Insightful)
My experience with FreeBSD is certainly not wonderful in this area. I have a FreeBSD machine that runs a single service (it's from a manufacturer and works with some specialized industrial equipment). This service is closed source, poorly written, and crashes all the time. The manufacturer's developers hacked together all kinds of scripts using cron to try to keep it running, which more often than not led to fork bombs and crashed the system completely on a regular basis.
I recently updated the box, moving to the very latest version of FreeBSD, and patching the binary to deal with changes to some system calls. I was pretty stoked because I thought I could now ditch all the cronjob hacks and perhaps use some kind of process supervision that surely the latest version of FreeBSD has.
To my surprise, FreeBSD offers no such thing out of the box. Only run-once shell scripts make up the init system. If I want process supervision most people recommend either compiling and installing daemontools (ugh), or finding some other third-party system. I eventually settled on supervisord which I have used in the past before system. It works well. But it's not part of FreeBSD proper.
Hardly elegant. I'll take systemd's simple and easy-to-use unit files any day.
name= (Score:2)
Why would my path contain an equal sign? And i suppose there needs te be a folder named âoename=âoe in the PWD where i run the command that polkit executes.
So just running
PATH=name=abcd some_polkit_command
Would do the trick just by itself? Or is it only the PATH that a root shell has access to?
Re: (Score:2)
This is a local privilege escalation. The attacker can set PATH to whatever they like before calling pkexec because they are logged in.
Why PwnKit (Score:5, Funny)
What utterly stupid code! (Score:5, Informative)
Who writes crap like this? And in an suid binary, no less! The problem basically is
for (n = 1; n < (guint) argc; n++) {...}
...
Very obviously, argc can be 0. This gross error indicates a lack of even a basic clue as to how argc/argv works. There is also absolutely no validation on argc to make sure it is >= 1. Again, in a frigging suid program. Incredible. Then they make it worse by writing argv[n].
Even copy/paste coding for argc processing would have been better. The first few Duckduckgo links with examples _all_ do it right. There is one (!) that starts n at 1, but they make sure that n is greater than 0 before.
The people at Qualys probably found this with some utterly simple fuzzing, which means some people will have known about it for a long, long time as that is a basic, cheap and completely standard approach to look for vulnerabilities in commandline programs.
Re:What utterly stupid code! (Score:5, Informative)
Also note that to fix it, they added a value check on argc not directly before it is used, but far enough away that somebody may not connect the two. Oh, and they do utter crap like jumping out of the for-loop with a "goto" or messing with the loop counter within the loop. This is really, really crappy code written by people that think they are smart.
Incredible. That code should be indented down 6 feet and covered with dirt.
Re: What utterly stupid code! (Score:2)
It sounds more like chutzpah, go on accuse him of intentionally introducing exploits he dares ya. He'll ever use programming techniques only found in obfuscated coding contests.
Re: (Score:2)
Actually, this code is not a problem, because if argc is 0 the loop will not be executed.
This code cannot create a memory corruption problem...
Re:What utterly stupid code! (Score:4, Informative)
The post is misleading. As you say the loop won't execute, the problem is that after the loop the program accesses argv[n] on the assumption that it's the last argument.
Obviously this is a problem if argc is zero, but it's presumably also a problem if argc is 1.
Re:What utterly stupid code! (Score:4, Insightful)
Actually, the problem is that the loop still sets n to 1 even of it does not run. And that value of n gets used later which creates the vulnerability. Yes, that is really shoddy coding.
Re: (Score:2)
Not correct. The part "n = 1" gets executed and that is the problem and causes the vulnerability because the value of n gets used later.
Re: (Score:3)
C "for" loops perform iteration test before starting. So if n = 1 and argc = 0, the loop will not run.
The question "Who writes crap like this?" could also be asked of your overly heated message with incorrect analysis of the code.
Re: (Score:2)
Wrong. n is set to 1 and that causes the vulnerability. Yes, n gets used after the loop and is assumed to be valid.
As to crap code, I invite you to read the pkexec sources and then again claim that this is reasonable code.
Re: (Score:2)
for (n = 1; n < (guint) argc; n++) {...} ...
Very obviously, argc can be 0. This gross error indicates a lack of even a basic clue as to how argc/argv works.
Leave it to gweirhir constantly mocking everyone elses intelligence to post something like this and get modded +5 for it.
I would ask if 1 is less than 0 but I'm afraid someone will say YES.
Re: (Score:2)
Well, you have obviously not looked at the code or the analysis of the problem. How pathetic.
The little detail you are unaware of is that the vulnerability is not _in_ the loop but _after_ it and it uses n which gets set to 1 by the loop even if the loop does not run.
And that nicely explains why I get up-modded and you do not.
Re: (Score:3)
Re: (Score:2)
This is why you don'
Re: (Score:2)
And that is exactly it.
The person that wrote the suid program pkexec is simply incompetent and should never have been let near anything this critical. Probably (at that time) a bright-eyed newbie that gleefully created the functionality and never even thought about the possible failure-modes and what they could do. If this was traditional engineering, he would at the very least lose his job over that.
Re: (Score:2)
Yes. But
a) In security critical code anybody with the least amount of actual competence verifies _all_ assumptions before relying on them and argc > 0 is an assumption.
b) You can call it with argc == 0 and somebody writing security critical code would have known that this was possible.
Incompetence and arrogance, the usual story. Also the source code of pkexec looks like something a beginner wrote.
Re: (Score:2)
The problem is that n gets set to 1 and n gets used later.
Read the full analysis if you want the details: https://blog.qualys.com/vulner... [qualys.com]
There's no excuse for this piss poor programming (Score:2)
This is a school boy error and should have been picked up years ago. The fact that such a basic bug hasn't been spotted in all this time shows that no one has bothered to vet this rather critical code - or if they did then not this boring enviroment variable part. It also doesn't say a lot about the skills of the original programmer if he can't even get something this fucking simple working correctly.
I'm not going to blame OSS and community dev because I've seen similar bugs in commercial software I've work
Re:There's no excuse for this piss poor programmin (Score:5, Insightful)
I'll go a step further. It's not safe to write C code without robust automated vulnerability scanning/fuzzing before you release it. And even then it's a risk.
As long as we have memory-unsafe languages like C we will have an endless stream of vulnerabilities, because humans aren't perfect.
Re: (Score:3)
Indeed, and given polkit's own description:
polkit is a toolkit for defining and handling authorizations. It is
used for allowing unprivileged processes to speak to privileged
processes.
Sounds like the kind of software that should be under EXTREME scrutiny.
From the bug report (I think) (Score:2)
https://seclists.org/oss-sec/2... [seclists.org]
"The bug is caused by an integer underflow ... [which] results in miscalculation of a valid max length. A bounds check is present ... however, if the value of size is greater than or equal to 4095, the unsigned subtraction will underflow ... so the check will not trigger. "
Surely this generates a compile time warning ?!?!?!?!?
I cannot tell you how many serious bugs I have fixed which were a direct result of some ass-hat totally ignoring compiler warnings.
Re: (Score:3)
No, that's a different thing. This just initialized a variable to 1, realized argv[1] wasn't a program argument, and proceeded to use it anyway.
Debian updated (Score:2)
Looks like my machines got Debian autoupdates this morning:
> 2022-01-26 06:11:04 status installed policykit-1:amd64 0.105-25+deb10u1
Master Control Program (Score:2)
Re: (Score:2)
Systemd solved some real problems on GNU/Linux. But it is now used as a trojan horse to replace every piece of code that sits between the kernel and the user applications by new tools written by script kiddies who think all the experience we got through decades of UNIX development is worthless and who think they know better.
They don't, their "new" and "better" tools have the same bugs that were fixed decades ago. The only things they are better at is being interdependant, breaking compatibility with existin
Re: (Score:2)
You certainly aren't an expert and neither apparently are any of the other anti-systemd folk above. It's almost comical to read if it weren't laced with such bile and personal attacks on one of the developers.
polkit is on most systems that don't have systemd as well. No MCP there.
Re: (Score:2)
Re: (Score:3)
Sendmail still wins.
But this is up there with the bash problem from a few years ago.
Re: (Score:2)
I know the bash one as that was pretty recent, but whats the sendmail one? (maybe I only care of postfix and missed it?)
Re: (Score:3)
... but what's the sendmail one?
Probably thinking of the Morris Worm [wikipedia.org] in 1988.
I was a Unix sysadmin at NASA LaRC, and at work, when that hit and went through the building unplugging network cables from Sun workstations, etc... before the network admins were able to isolate the LANs.
Re: (Score:2)
That's the one. It was terrifying because nothing like it had happened before, there was no way to easily track it, or stop it, except shut down your mail system. And that's only if you knew it was happening, because there was no threat network, no web, and the best way to find out about it was through your compromised email system.
Re: (Score:2)
This one fits the bill.
https://vuldog.com/cve/cve-200... [vuldog.com]