Here's a shorter summary of the vulnerability:<p><pre><code> for (n = 1; n < (guint) argc; n++)
</code></pre>
Usually, after that loop, n equals argc (or could be less than argc if the loop breaks or something). But if argc is 0, then n will equal 1 after. Later on, the program writes to argv[n]. If argc is 0, then argv[n] is argv[1], which is out-of-bounds, but happens to refer to the same place as envp[0] (at least on Linux). This lets the attacker set an arbitrary environment variable, after ld.so(8) already sanitized the environment. In particular, setting the GCONV_PATH environment variable (which is one that would have been removed during sanitization) will cause pkexec to load and execute code from a .so file in an attacker-controlled directory.
The piece of polkit that this exploits was blogged about in 2013: <a href="https://ryiron.wordpress.com/2013/12/16/argv-silliness/" rel="nofollow">https://ryiron.wordpress.com/2013/12/16/argv-silliness/</a>
Setuid programs like pkexec or sudo are hard to get right… Here an example of using systemd-run (not setuid, and the wrapper script neither) for something similar like sudo (but it uses a systemd unit instead of a direct child process in the same process group):<p><a href="https://gist.github.com/pothos/73dd4f7694acc3b6bbed614438f6e2b1" rel="nofollow">https://gist.github.com/pothos/73dd4f7694acc3b6bbed614438f6e...</a><p>Since polkit is used (but not the setuid pkexec, this was the point of this exercise) there is still one setuid binary invoked for the PAM check, though.
From Wikipedia for Polkit<p>> It is also possible to use polkit to execute commands with elevated privileges using the command pkexec followed by the command intended to be executed (with root permission).[7] However, it may be preferable to use sudo, as this command provides more flexibility and security, in addition to being easier to configure.[8]<p>> A memory corruption vulnerability PwnKit (CVE-2021-4034[10]) discovered in the pkexec command (installed on all major Linux distributions) was announced on January 25, 2022.[11][12] The vulnerability dates back to the original distribution from 2009. The vulnerability received a CVSS score of 7.8 ("High severity") reflecting serious factors involved in a possible exploit: unprivileged users can obtain full root privileges, independent of the underlying machine architecture, regardless of whether the polkit daemon is running or not.<p>Does a lot of software depend on pkexec? How could it be secured to be recommended over sudo?
This is a great write-up, and also a great illustration of something that's fundamentally broken in the way Linux and Unix think about security.<p>`suid` binaries exist for a good reason: they allow users to escalate their privilege in limited ways under control of the system. Good, but obviously risky if the user can subvert that control. The offered solution to that risk is where the problem comes in. Developers of suid binaries are just asked to write them really, really carefully. There are some documents to describe how to do it carefully, but they pretty much assume that code can be developed without bugs, as long as we're careful enough. At least initially, there was no help, no tooling, no verification, no testing, nothing. Just real, real careful.<p>Unfortunately, instead of seeing the absurdity of that situation, many people have gone all "no true Scotsman" on it. "If you were a real Unix Developer then you wouldn't make mistakes like that." We don't need no stinking tools, we're Real Programmers.<p>The situation has been improving, but the underlying mechanism is still super popular and here to stay. It's either time to stop pretending that local `root` means anything, or start taking stuff like this much much more seriously. Some people sure are, but it hasn't pervaded the culture yet.
There is already POC code published: <a href="https://github.com/mebeim/CVE-2021-4034" rel="nofollow">https://github.com/mebeim/CVE-2021-4034</a>
There's zero reason for policykit to be installed on multiuser systems or servers. This is just a part of bizarre obsession with "new tools" bullshit coming from RedHat and the inept software developers it accumulates.<p>The following should be the output of "find / -type f -perm -4000 -o -perm -2000" on a VM. If it is a container, you might need an "su" and/or "sudo" and maybe, if for some reason you are using a cron internal to the container (but why?!), crontab.<p>/usr/bin/chfn<p>/usr/bin/chage<p>/usr/bin/chsh<p>/usr/bin/sudo<p>/usr/bin/crontab<p>/usr/bin/su<p>/usr/bin/ssh-agent<p>/usr/bin/newgrp<p>/usr/bin/passwd