Serious Linux security issue: pwnkit: Local Privilege Escalation in polkit’s pkexec (CVE-2021-4034)
Daniel Nashed 26 January 2022 23:19:55
This is pretty bad, but can be only exploited when the user already has local access.
Now looking into why the package is installed at all by default on many systems, which don't even run a graphical interface is not understandable.
And how can a bug like this happen at all?
Here is the source of the information --> https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt
And here are some technical details:
The package is used to allow certain applications to gain root access -- similar to what sudo does.
The binary has the setuid set, which makes it execute as root.
The application itself has to control who should gain root access (setuid permission can be only set for binaries -- not for shell scripts).
In this case the binary has a really stupid bug, that allow a local attacker to get root access on the machine.
The package that was installed on my machine is the following:
polkit-0.115-12.el8.x86_64 : An authorization framework
Repo : baseos
Filename : /usr/bin/pkexec
And here is the binary affected:
ll /usr/bin/pkexec
-rwsr-xr-x 1 root root 31032 May 26 2021 /usr/bin/pkexec*
It might be installed in many Linux machines of different distributions.
My CentOS Stream 9 had it not installed.
After quickly looking into it, I removed it from all my systems via
yum remove polkit -y
Here are details about the fix I found: https://gitlab.freedesktop.org/polkit/polkit
But clearly the fix for me is to remove the package.
RHEL 8 provided a new version dated December. But CentOS still does not have it.
Update:
Of course you have to check for yourself if you have software like "cockpit" using this software to have system tasks executed.
But for me this is the easiest way to get rid of software like cockpit -- a web based admin tool.
I wasn't even aware it is installed by default.
Usually software that is really needed will complain if you try to remove a package they have strong dependencies.
If you need to keep the binary and no fix is available yet, you can change the permissions as suggested in the security advisory instead.
This incident clearly lets me look into my machines again and question packages installed by default on the distributions I am using.
I blogged about VMware PhotonOS a while ago. They do a great job looking into dependencies they really need and stripping down their images.
Specially on the Docker side.
The Domino Docker image and other Domino base images don't have the software installed by the way.
It is already a more stripped down image, without admin tools like the networkmanager and others.
You really have to balance between convenience and security.
I would see that on a server those kind of admin tools are not needed and software that manages access to restricted resources that usually need "root" permissions.
There might be other software that needs it. So you have to carefully check what to remove.
Thanks Toni for your feedback. My statement from last night was about what I did and that was a decision I took based on the installed software packages that needed it on my machines.
It was a bonus to get those other tools removed in my case :-)
-- Daniel
- Comments [4]
![[HCL Domino]](../lotus-domino.gif){kind=small}
![[Domino on Linux]](../domino-linux.gif){kind=small}
![[Nash!Com]](../nashcom.gif){kind=small}
![[Daniel Nashed]](../daniel-nsh.gif){kind=small}