RHSB-2022-001 Polkit Privilege Escalation - (CVE-2021-4034)

Executive summary

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.

Technical summary

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.

Mitigation

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:

debuginfo-install polkit

3. Create the following systemtap script, and name it pkexec-block.stp:

probe process("/usr/bin/pkexec").function("main") {

if (cmdline_arg(1) == "")

raise(9);

}

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:

rmmod stap_pkexec_block

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.

Technical details

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.

Service impact

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.  

^[1] Advisory/Update link will be added once updates are live.

^[2] What is the Red Hat Enterprise Linux Extended Update Support (EUS) Subscription?

^[3]What is Advanced mission critical Update Support (AUS)?

^[4]What is the Red Hat Enterprise Linux SAP Solutions subscription?

^[5] 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.

Diagnose

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.

Ansible Playbook

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. 

FAQ

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.

Acknowledgements

Red Hat thanks the Qualys Research Team for reporting this vulnerability.

References

https://access.redhat.com/security/cve/CVE-2021-4034

https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt

How to use GPG to verify signed content from Product Security