How to Mitigate Your Risk from Dirty Pipe/CVE-2022-0847

Dirty Pipe, CVE-2022-0847, allows non-root user accounts to gain root-level privileges. With the elevated privileges, the user can modify the integrity of files, including read-only files, access files they wouldn’t usually have access to, impacting confidentiality. In extreme cases, they could shut down services or servers, impacting the availability of the services running on them. Beyond the server, this vulnerability also impacts Android-based phones. The problem is present on all Linux kernels going back to kernel 5.8. The problem has been confirmed fixed in versions 5.16.11, 5.15.25, and 5.10.102.

Threat Summary 

The recently announced flaw in CVE-2022-0847 is in the Linux Kernel. It allows for multiple types of privilege escalations, through multiple publicly available programs that any user can run. Examples include:

• Adding SSH keys to the root SSH authentication key file, allowing any user to log in with root-level access.
• Overwriting file content with their own data, including read-only files.
• Direct command line access as the root user, giving the threat actor access to everything on the system.
• Creating new accounts on the system to maintain access
   

What Coretek is Doing for Customers

Coretek is informing customers of the issue, providing analysis steps to see if their systems have been compromised, and recommending that users update the kernel running on their Linux-based systems to the known patched version. 

Coretek Recommendations

Perform a file and system review looking for possible signs of exploitation

Coretek advises customers to review the following items for signs of compromise:

• Review the /tmp directory looking for a directory called sh/tmp/sh
• Check the /etc/password and /etc/shadow files for unknown accounts.
• Confirm that the root account still has :x: after the user name in /etc/password.
• If the x is missing between the colons it means that the root password has been removed, and anyone can escalate to root.
• Look under /root/.ssh_authorized_keys for any unknown keys or users.
• Review the /var/logs/secure or /var/log/auth.log files for logins.
• File name is based on Linux distribution type RedHat based systems use /var/log/secure, Debian/Ubuntu based systems /var/log/auth.log.
   

If Indicators of compromise are found, initiate your Incident Response Plan

If you find a host artifact that indicates your system has been compromised, you’ll need to start your Incident Response Plan for compromised systems.

Patch to the latest version of the Kernel.

The known patched kernel versions are 5.16.11, 5.15.25, and 5.10.102. If your system is not showing a sign of compromise, update to a known patched kernel version.

If your system is compromised, see the comment above about starting the Incident Response Plan before patching. Your Incident Response team may need information from the system before upgrading the kernel.

Disable Root Logins for SSH

One of the recommendations for hardening a Linux system is to disable root logins; this prevents direct access to the system as the privileged root user. Users should log in with their regular non-privileged accounts and then escalate to root using the sudo command.

To disable Root Login, change “PermitRootLogin” to “no” in /etc/ssh/sshd_config. Then restart the sshd server.

References and Additional Resources

If you are a Coretek customer, have any questions about Coretek remediation actions or your support agreements with Coretek, or are a visitor who would like more information, please get in touch here.

• Linux Has Been Bitten by its Most High-Severity Vulnerability in Years | Ars Technica 
• New Linux Bug Gives Root on All Major Distros, Exploit Released