CVE-2021-4043 - Page 1
Forum section: electronics / general

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 25, 2022, 09:59:07 pm
content: A 12-year old root exploit still open in PolicyKit was recently published as CVE-2021-4043.It is a garden-variety root exploit: any user knowing about the bug can easily get root privileges on any Linux system that has PolicyKit installed. And that's basically all of them, except the 'anti-systemd nutjobs' like myself.See Steven Vaughan-Nichols'article at ZDNet.I've often said the code by these authors is shit, but nobody cares: apparently anything new is always better than old, because it is new, and therefore better; besides, these authors have nice social skills, so they must be better than us smelly long-haired Unix hippies anyway.

author: magic
author_rank: Super Contributor
timestamp: January 26, 2022, 04:18:28 pm
content: I'm not enough of an anti-systemd nutjob, apparently. The crap is still installed as a dependency of some package.Punishment for using a sellout distributionIn retrospect, I should have donechmod -xon all those binaries long ago

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 26, 2022, 04:36:33 pm
content: The funniest thing about PolicyKit is on itsDebian Wiki page:QuoteWant to know who authored PolicyKit? You're not supposed to know; theAUTHORS filein the upstream freedesktop.org gitlab repo is, of course, empty.Here isthe closest thing to an author list I could find.

author: magic
author_rank: Super Contributor
timestamp: January 26, 2022, 04:40:48 pm
content: It's starting to look like a replacement for sudo which does the exact same thing but without receiving the same scrutiny

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 26, 2022, 05:46:48 pm
content: If you do not work for RedHat or have a commercial contract with them, and do not belong to the PolicyKit-DBus-AccountsService social inner ring, how do you even point out critical flaws in them? Post a bug or gitlab message, and it'll be closed with a "go troll somewhere else" -type snotty response.Related story, feel free to skip:TheApache suEXEC Security Modelis insane. Specifically, enforcing point 18, that a CGI executable can only be executed as the owner user/group, means that any script you execute using suEXEC will be able to modify itself. It also means it is impossible to determine whether a new executable script was created by a human administrator, or by any script executed using suEXEC, allowing script drops.Years ago, I tried to explain why the opposite, requiring that a CGI script be executed with at least the owner user being different than the owner of the file, with local user accounts created and reserved for CGI scripts, is necessary to stop the proliferation of script drops and pwning of sites via small flaws in their upload scripts."Too hard." "That would mean we'd have to create two user accounts per human user, instead of one; we don't wanna." "Plesk does not support that." "cPanel does not support that."It is quite possible to create web sites where common bugs cannot be escalated into security holes; where only the login, logout, and user account management pages need to be carefully vetted to avoid data leaks, since the other pages simply do not have access to the sensitive information at all. And it isn'thard, it is just done differently than what is currently commonly assumed is the normal way of doing things.Compare that to policykit. You get some asshats from RedHat producing privilege escalation software with "ToDo: explain how this works (later)" getting to insert their crappy code into just about every distribution, because of company politics and social pressure among projects. (Just go look at how DBus, PolicyKit, and AccountsService all tie in together; but we warned, you'll get angry and/or depressed, if you understand the implications.)Technical merits do not matter –– hell, for PolicyKit they were never even described publicly! The only thing they told was that using sudo for applications is too hard!What matters, is that it is done by Nice People who do not occasionally swear and are always Politically Correct. What we learned from the Unix world (and its predecessors) about security and what works, does not matter, because New Is Always Better Than Old. Mark my words: the PolicyKit authors will not receive a single granule of shit (outside from 'anti-systemd nutjobs' like myself) from this. Nobody will note the abovementioned ToDo, nobody will comment on the empty AUTHORS file.I'd prefer people fuck me with a cactus instead of this crazy shit.

author: PKTKS
author_rank: Super Contributor
timestamp: January 26, 2022, 06:18:32 pm
content: Although every distro out there has POLKIT by default...Mostly used by fancy login greeters which ditched plain Xauth...indeed it sREQUIREDby systemd as one more magic wand...Even the LFS build made to inter-operate systemd put that as required..The 2 pieces of the NON -systemd safety rules are:- ditch the fancy unsafe greeters which require external tools...- use a common sense account (likenobodyor other) to handle such odd tools..This is a compile time define option...BTW THANKS FOR THE HEADS UP !!! Nominal..Paul