RHSB-2022-001 Polkit Privilege Escalation - (CVE-2021-4034)
Insights vulnerability analysis
Red Hat is aware of a vulnerability found in pkexec that allows an authenticated user to perform a privilege escalation attack.
The polkit package is designed to define and handle policies that allow unprivileged processes to communicate with privileged processes on a Linux system. Pkexec, part of polkit, is a tool that allows the user to execute commands as another user according to the polkit policy definitions using the setuid feature. The vulnerability found in pkexec allows an unprivileged local attacker to escalate privileges, bypassing any authentication and policies due to incorrect handling of the process’s argument vector.
The primary risk for customers is the possibility of an unprivileged user gaining administrative privileges on the affected systems. The attacker must have login access to the target system to carry out the attack.
This issue is assigned CVE-2021-4034 rated with a severity impact of Important.
The following Red Hat product versions are affected. “Affected” means that the vulnerability is present in the product’s code, irrespective of the usage or mitigations, which may address if the product is vulnerable.
Red Hat Enterprise Linux 6
Red Hat Enterprise Linux 7
Red Hat Enterprise Linux 8
Red Hat Virtualization 4
Further, any Red Hat product supported on Red Hat Enterprise Linux (including RHEL CoreOS) is also potentially impacted. This includes:
Product containers that are based on the RHEL and ship polkit package. These images are updated regularly, and container health indicating whether a fix to this flaw is available can be seen in the Container Health Index, part of the Red Hat Container Catalog.
Products that pull packages from the RHEL channel (this includes layered products such as Red Hat OpenShift Container Platform, Red Hat OpenStack Platform, Red Hat Virtualization, and others). Ensure that the underlying RHEL polkit package is current in these product environments.
To determine if your system is currently vulnerable to these flaws, see the Diagnose section below. Additionally, an Ansible playbook for automatic remediation is provided below.
The pkexec program does not properly validate the amount of arguments passed to it. This issue eventually leads to attempts to execute environment variables as commands. When properly exploited, this issue leads pkexec to execute arbitrary code as a privileged user, granting the attacker a local privilege escalation. Refer to CVE-2021-4034 for more details.
Red Hat Product Security strongly recommends affected customers update the polkit package once it is available. For customers who cannot update immediately, the issue can be mitigated by executing the following steps:
1. Install the following required systemtap packages and dependencies: https://access.redhat.com/solutions/5441.
2. Install polkit debug info:
3. Create the following systemtap script, and name it pkexec-block.stp:
if (cmdline_arg(1) == "")
4. Load the systemtap module into the running kernel:
stap -g -F -m stap_pkexec_block pkexec-block.stp
5. Ensure the module is loaded:
lsmod | grep -i stap_pkexec_block
stap_pkexec_block 434176 0
6. Once the polkit package is updated to the version containing the fix, remove the systemtap generated kernel module by running:
After using the rmmod command, a system reboot isn’t required.
Note: If the system is rebooted, the module generated by the systemtap needs to be reloaded into the kernel. To do that, navigate to the directory where the mitigation script was created and follow steps 4 and 5.
Once the mitigation above is performed, pkexec will continue to work as expected for legitimate use cases.
Note: This mitigation doesn't work for Secure Boot enabled systems. SystemTap would require an external compiling server to have the ability to sign the generated kernel module with a key enrolled into the Kernel's keyring.
When starting a new process, the Linux Kernel creates an array with all the command arguments (argv), another array with environment variables (envp), and an integer value representing the argument count (argc). The Linux Kernel positions both the argument array and the environment variables array in a contiguous way in the memory. Another default behavior is how the first value of the argument array contains the executable name (ex. pkexec for pkexec executable), which implies that any arguments sent to the process by the user are positioned after this value.
Pkexec does not validate the argument count, it assumes it will always be at least 1, and that the second value is either NULL, or the command to be executed by pkexec as a privileged user. If an attacker successfully forces the argument array to be empty, pkexec will interpret content from the environment array as the application to be executed. An attacker can leverage this by manipulating these variables to contain specific values and payloads, allowing it to be executed as a privileged user without any authentication to be requested.
The following Red Hat Services are directly affected:
OpenShift Dedicated (OSD)
Azure RedHat OpenShift (ARO)
The impact on Services is Low, since to use polkit, the user should use a graphical or a CLI to authenticate to get a service with polkit acting as the authentication agent. In OSD, the graphical usage is not relevant; in CLI usage, the user will use the OC command to authenticate to the OSD cluster.
Also, OSD does not make any special use of polkit in production clusters. In OSD, on one of the test OSD cluster's master, timedatex has a dependency on polkit. Therefore, for OSD/ARO, the impact is Low.
Updates for affected products
Red Hat customers running affected versions of these Red Hat products are strongly recommended to update as soon as errata are available.
Customers are urged to apply the available updates immediately and enable the mitigations as they feel appropriate.
Red Hat Enterprise Linux 8
Red Hat Enterprise Linux 8.4.0 Extended Update Support 
Red Hat Enterprise Linux 8.2.0 Extended Update Support 
Red Hat Enterprise Linux 8.1.0 Update Services for SAP Solutions, Advanced Update Support ,
Red Hat Enterprise Linux 7
Red Hat Enterprise Linux 7.7 Update Services for SAP Solutions, Advanced Update Support ,
Red Hat Enterprise Linux 7.6 Update Services for SAP Solutions, Advanced Update Support ,
Red Hat Enterprise Linux 7.4 Advanced Update Support 
Red Hat Enterprise Linux 7.3 Advanced Update Support 
Red Hat Enterprise Linux 6 Extended Life-cycle Support 
Red Hat Virtualization 4 for Red Hat Enterprise Linux 8
Red Hat Virtualization 4 for Red Hat Enterprise Linux 7
 Advisory/Update link will be added once updates are live.
 What is the Red Hat Enterprise Linux Extended Update Support (EUS) Subscription?
 What is Advanced mission critical Update Support (AUS)?
 What is the Red Hat Enterprise Linux SAP Solutions subscription?
 An active Extended Life-cycle Support (ELS) subscription is required for access to this patch. Please contact Red Hat sales or your specific sales representative for more information if your account does not have an active ELS subscription.
A vulnerability detection script has been developed to determine if your system is currently vulnerable to this flaw. To verify the authenticity of the script, you can download the detached OpenPGP signature as well. Instructions on how to use GPG signatures for verification are available on the Customer Portal.
Additionally, an Ansible playbook is available which automates the mitigation described above. This playbook will install the packages necessary to use systemtap, and will then create and install a systemtap script to prevent the use of the pkexec command without arguments. This mitigation will need to be re-applied after a reboot, which can be achieved by re-running the playbook.
To use the playbook, define the extra variable HOSTS with the Ansible inventory name of the hosts to which the mitigation will be applied. For example,
ansible-playbook -e HOSTS=web,ns1,mail CVE-2021-4034_stap_mitigate.yml
To verify the authenticity of the playbook, you can download the detached OpenPGP signature. Instructions on how to use GPG signature for verification are available on the Customer Portal.
Q: After applying the fix, is there a need to restart any service or system to ensure the system is not vulnerable?
A: There’s no need to restart any service or reboot the system. The fix is applied on pkexec, which is a tool from the polkit suite. It’s a single instance run, and once the update is applied, the next time pkexec is executed, it should load the patched application. When the update is applied, the update process restarts the polkit service.
Q: Is there a need to restart the system or service after applying the recommended mitigation ?
A: There’s no need to restart the system after applying the mitigation. Systemtap itself will make sure the kernel module is loaded.
Q: Is it safe to remove the setuid permission from pkexec binary as a mitigation?
A: Red Hat does not recommend removing the setuid bit as it will cause breakage on the system. Removing the setuid permission from the pkexec binary will prevent it from working properly for legitimate use cases. This means that any application which relies on pkexec execution will stop working, possibly causing unexpected system errors and behavior. While the Qualys advisory on this vulnerability listed removing setuid as potential mitigation, this is determined to not be a viable mitigation for our customers without causing breakage. Red Hat provided an alternative mitigation which, when applied, does not have a negative impact to the functionality of pkexec. Any mitigation used should be only on a short-term basis until released patches can be applied.
Q: What is the impact on the OpenShift Container Platform?
A: In OpenShift Container Platform (OCP), the polkit package is shipped in the RHCOS, which is used in cluster nodes. Access to the OCP nodes is restricted to the cluster administrators only. If someone can connect directly to the OCP node, and will be a root user already, then the existence of the vulnerable polkit package doesn't change anything.
The polkit package is also shipped in several OCP container images used by cluster administrators to manage the OCP cluster. These images are run as privileged containers, so anyone who can gain access to these containers already has full admin access.
Q: I’m running Red Hat Enterprise Linux 7.x with Docker. After the restart, my containers are not accessible through the network anymore. What should I do?
A: When Docker starts, it sets net.ipv4.ip_forward to 1, allowing IP forwarding, which is needed to make containers accessible through the network. However, it is not persisted in the machine configuration. When updating the polkit package, the polkit service will automatically restart on the Red Hat Enterprise Linux server and ends triggering the system to reload the kernel configuration. This overrides non persisted sysctl entries, causing the Docker containers to be inaccessible through the network. To avoid such behavior, the system admin needs to make sure the net.ipv4.ip_forward desired value is persisted into sysctl configuration files. See How to set sysctl variables on Red Hat Enterprise Linux for more information regarding this procedure.
Red Hat thanks the Qualys Research Team for reporting this vulnerability.
How to use GPG to verify signed content from Product Security
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.
Current Customers and Partners
Log in for full accessLog In
New to Red Hat?
Learn more about Red Hat subscriptions
Thanks for the script.
Script seems to be broken. Only looks for the version with '_9', which currently doesn't exist --at least on my Satellite server, maybe after update today. The package without the '_9' is installed, but still gets called out as vulnerable.
[kirkhto1@DVUSFW-SS263339 ~]$ ./cve-2021-4034--2022-01-25-0936.sh
This script (v1.0) is primarily designed to detect CVE-2021-4034 on supported Red Hat Enterprise Linux systems and kernel packages. Result may be inaccurate for other RPM based systems.
Detected 'polkit' package: polkit-0.112-26.el7.x86_64 This polkit version is vulnerable. Follow https://access.redhat.com/security/vulnerabilities/RHSB-2022-001 for advice.
polkit-0.112-26.el7was first released on 2020-03-31 and is vulnerable to CVE-2021-4034. This is the version that appears to be installed on your system.
polkit-0.112-26.el7_9.1was first released on 2022-01-25 and is not vulnerable to CVE-2021-4034.
The detection script is designed to detect CVE-2021-4034 on supported Red Hat Enterprise Linux systems. The script doesn't try to fix anything. As such, it seems the script might be working correctly in this case. If my analysis is incorrect, I apologize.
It seems that this is the security advisory relevant for your system: https://access.redhat.com/errata/RHSA-2022:0274
I get that, however I hope you are wrong as the version part of the string is identical... so what that it was built for 7.9 or 7.x. If 'el7_9.1' is now supposed to be a part of the version string that kind of stinks trying to keep track of everything. Then again since Red Hat versions can't be matched to upstream versions, I guess it's a crapshoot anyway.
Red Hat practices security backporting, where a given version receives fixes. The release part of the RPM's Name-Version-Release changes on such occurrences.
polkit-0.112-26.el7_9.1has the following components:
Please refer to the following resources:
Hi, Do you have an offline solution, please ? stap command -line seems to need to have servers open to the outside.stap -F -o /root/pkexec-block.log -S 1 -m stap_pkexec_block -g /root/pkexec-block.stp
Using a compile server. Unable to find a suitable compile server. [man stap-server] No servers online to select from. Passes: via server failed. Try again with another '-v' option. The kernel on your system requires modules to be signed for loading. The module created by compiling your script must be signed by a systemtap compile-server. [man stap-server] --use-server was automatically selected in order to request compilation by a compile-server.
@Jakub Svoboda : No news ?
unfortunately we currently don't have any mitigation for scenarios where Secure Boot is enable. This happens because systemtap needs an external signing server to sign the generated kernel module with a key enrolled in the MOK, otherwise the kernel won't be able to load the module.
the ansible play book is not patching REL 7 ? - when: (ansible_distribution_major_version == '6' or ansible_distribution_major_version == '8') name: (RHEL 6/8) Install polkit debuginfo command: debuginfo-install -y polkit
is this intentional as the detection script is still finding a problem after running this playbook ?
The detection script intentionally doesn't detect mitigations. The detection script is designed to detect CVE-2021-4034 on supported Red Hat Enterprise Linux systems based on RPM Name-Version-Release.
The Ansible playbook is designed to apply the mitigation described in https://access.redhat.com/security/vulnerabilities/RHSB-2022-001 to supported Red Hat Enterprise Linux systems. On each major RHEL version, the setup steps are different. The step you describe is one of the setup steps.
If you see that the Ansible task "Install systemtap script" doesn't fail and if the two following points are true, then the Ansible playbook works for you:
pkexeccommand (without any arguments) in the command line of the affected machine fails with a
lsmod | grep stap_pkexec_blockin the command line of the affected machine returns a line beginnning with
Red Hat Product Security strongly recommends affected customers update the polkit package.
«While the Qualys advisory on this vulnerability listed removing setuid as potential mitigation, this is determined to not be a viable mitigation for our customers without causing breakage»
This is unhelpful, what does pkexec is used for if one install only the core plus required packages for a certain service?
In our case it means 24 new packages (4 of which an upgrade), and most of them development tools, while removing polkit only removes polkit itself, tuned (which only needs it for authenticating the root password if called without being root), and polkit-pkla-compat.
What @core packages require pkexec, Red Hat? I see none. We use none.
The less intrusive and best option of all is actually temporarily removing the setuid bit.
The advised Red Hat solution is very intrusive and may severely break configuration standards of enterprise setups, something which is a big nono of ISO20000, PCI, SWIFT, and other high security and infrastructure normalization standards.
Hi, the Red Hat provided Mitigation is a short term solution that can be safely used without breaking deployments. We cannot make the same statement for alternative mitigations. We have released updated software that should be applied to resolve this CVE. If you have specific questions related to polkit, its dependencies, and usage - please do contact our Support team so that they can assist.
I am willing to explain in voice to anyone that needs it in order to understand, but no the mitigation proposed is impractical and unsafe in corporate enterprise segments: * requires installation of development packages and/or upgrade of current critical packages (eg, glibc which will then require a reboot) this alone is is viewed as a an availability issue, which makes it unsafe to do in a short urgency window * this is a major issue, specially in ISO20000, PCI, and other certifications * specially multiplied by hundreds if not thousands of servers * that are distributed across a deployment pipeline with managed update windows, against approved content-view versions that have been tested in the lower priority environments
And all for a small program that apparently nothing in a @core installation actually uses.
"Detected 'polkit' package: polkit-0.115-11.0.1.el8_4.1.x86_64 This polkit version is not vulnerable." <---- says the RHEL script which searches only against below (the el8) versions: 'polkit-0.115-11.el8' 'polkit-0.115-11.el8_2.1' 'polkit-0.115-11.el8_3.2' 'polkit-0.115-11.el8_4.1'
As I understand, the packages with minor version changes like polkit-0.115-11.x.y.el8 are also affected; it's only the higher versions like 13vers viz. polkit-0.115-13.el8 & polkit-0.115-13.x.y.el8 aren't vulnerable <-- would highly appreciate a (re)confirmation.
As for the first paragraph of your question, Red Hat has never built the
polkit-0.115-11.0.1.el8_4.1package. It seems that your system has a
polkitpackage that has not been built and provided by Red Hat. The detection script is primarily designed to detect CVE-2021-4034 on supported Red Hat Enterprise Linux systems.
One of your options to get the fixed and supported
polkitrelease is to open a support case via the Open a Support Case link at https://access.redhat.com/.
Another option to get the fixed and supported
polkitrelease is to see which repository
polkit-0.115-11.0.1.el8_4.1was installed from, disable that repository, and update
polkitfrom a Red Hat-supported repository. For example, the command
yum list polkit --showduplicateslists installed and available
polkitpackages, and lists the repositories they are from in the right-hand side column. On a standard RHEL8, the repository name should be
rhel-8-for-x86_64-baseos-rpms. The command
yum update polkitupdates
polkitto the highest version available in the enabled repositories.
More information about using
yumis available in the Configuring basic system settings guide for Red Hat Enterprise Linux 8. Namely:
As for the second paragraph of your question, this is not accurate. To provide a counterexample, Red Hat-built
polkit-0.115-11.el8_4.2is not vulnerable to CVE-2021-4034.
Red Hat practices security backporting, where a given version receives fixes. The release part of the RPM's Name-Version-Release changes on such occurrences.
polkit-0.115-11.el8_4.2has the following components:
For each product, the release part can change in different ways. Because of the way how features are backported to older versions and releases of packages in various channels for various products, simple numerical version comparisons can't determine whether a particular Red Hat-built RPM package is vulnerable to CVE-2021-4034 or not. This is the reason why the detection script checks against a list of vulnerable packages, without performing numerical version comparisons.
Here is an overview of the
polkitreleases for supported base Red Hat Enterprise Linux 8 available via
polkit-0.115-6.el8(vulnerable to CVE-2021-4034)
polkit-0.115-9.el8(vulnerable to CVE-2021-4034)
polkit-0.115-11.el8(vulnerable to CVE-2021-4034)
polkit-0.115-11.el8_4.1(vulnerable to CVE-2021-4034)
polkit-0.115-12.el8(vulnerable to CVE-2021-4034)
polkit-0.115-13.el8_5.1(not vulnerable to CVE-2021-4034 == the vulnerability is fixed in this name-version-release)
Please refer to the following resource to learn more about backporting: https://access.redhat.com/security/updates/backporting/
If the operating system you are running is not Red Hat Enterprise Linux but a derived distribution, there are supported and unsupported options to convert your operating system to Red Hat Enterprise Linux.
Thanks a lot @Jakub Svoboda for the elaborate & precise response : it was a OEL version I'd shared.
Their security team did, however, confirm that all versions below polkit-0.115-13.x are vulnerable for OEL ; on RHEL OS, I will go ahead with your reconfirmation as per the counter example shared.
BR Shah [Apologies for any late response; thought the reply had been posted 2 days back.]
RHEL7.9 servers with docker installed getting issues after polkit package update. There seems to be some network breaking in docker after update ? So restart of dcoker services or system reboot is required after polkit update ?
Hi Unix Team,
You had network breaking, so please check if net.ipv4.ip_forward is set persistently to 1 in files such as /etc/sysctl.d/*.conf or /etc/sysctl.conf.
If this parameter is set persistently no docker restart is needed.
I have a question, as we are using Mostly RHEL7.x (7.6-7.9) and we are using Satellite to steam the content, as we have currently "polkit-0.112-26.el7.x86_64" around the systems and "polkit-0.112-26.el7_9.1.x86_64" which we Just Published to be newer Version to replace the Vulnerability.
I have just a question to clear does it requires a reboot after doing "yum update polkit" ? or its just safe to do and keep the system running?
Hi Karn Kumar,
polkit-0.112-26.el7is vulnerable to CVE-2021-4034.
polkit-0.112-26.el7_9.1is not vulnerable to CVE-2021-4034.
Q: After applying the fix, is there a need to restart any service or system to ensure the system is not vulnerable?&
A: There’s no need to restart any service or reboot the system. (...).
yum update polkitto a fixed polkit version resolves the CVE-2021-4034 vulnerability, without needing system reboot and without needing service restart, and it is safe to keep the system running after that (with regards to CVE-2021-4034).
@Jakub, Many thanks for the same.. Is there any impact for running application as such while doing "yum update polkit"?
yum update polkitdoesn't interfere with other applications.
after mitigation script i got this output in rhel6 servers , uprobes output is getting.
it means mitigation worked as per this output, some body confrm this please
[root@lxjh228 /]# lsmod | grep -i stap_pkexec_block stap_pkexec_block 163449 0 uprobes 28877 1 stap_pkexec_block
Yes, the systemtap module was loaded correctly.
stap_pkexec_block is the module generated by the systemtap script uprobe is loaded as the systemtap module dependency.
my system is redhat version 7.5, 7.6 and no internet for update package how can i update package polkit offline? rpm -Uvh polkit-0.112-26.el7_9.1.x86_64.rpm right? Is it affected old kernel version 7.5, 7.6? if i will fix this vulner package polkit only
Hi juthathip kongpun,
If I understand you correctly, you are asking four questions:
1) Q: How can I update
polkitin Red Hat Enterprise Linux 7 offline?
Answer: Please refer to the following knowledge base articles:
How can we regularly update a disconnected system (A system without internet connection)?
How to update an offline Red Hat Enterprise Linux server without network connection to Red Hat/Proxy/Satellite?
2) Q: How can I update
polkitin Red Hat Enterprise Linux 7.5 and 7.6?
Answer: Red Hat Enterprise Linux 7.5 and 7.6 are not supported anymore. More specifically, they are not in any of these support phases: Full Support, Maintenance Support 1, Maintenance Support 2, Extended Update Support (EUS).
If you think that your deployments of Red Hat Enterprise Linux 7.5 and Red Hat Enterprise Linux 7.6 are still supported by Red Hat, please open a support case via the Open a Support Case link at https://access.redhat.com/.
3) Q: Is the kernel package affected by the vulnerability CVE-2021-4034?
Answer: No, the
kernelpackage is not affected by the vulnerability CVE-2021-4034.
4) Q: Will the command
rpm -Uvh polkit-0.112-26.el7_9.1.x86_64.rpmfix the vulnerability CVE-2021-4034 on Red Hat Enterprise Linux 7.5 and 7.6?
Answer: Red Hat Enterprise Linux 7.5 and 7.6 are not supported anymore. The package
polkit-0.112-26.el7_9.1.x86_64.rpmis designed to be installed on Red Hat Enterprise Linux 7.9 and has not been tested on older versions of Red Hat Enterprise Linux.
Additionally, https://access.redhat.com/support/policy/updates/errata contains an overview of support phases for various versions of Red Hat Enterprise Linux.
Maintenance Support 2 ended:
Extended Update Support (EUS) ended:
Thank you for your response :) The best solution, should i update RHEL from 7.5 to 7.9 (Latest of RHEL 7) instead update one package polkit ?