Nasty Linux Bug, CVE-2024-1086, is on the loose

A few months back, CVE-2024-1086, a nasty use-after-free vulnerability in the Linux kernel's netfilter, was revealed. With a  Common Vulnerability Scoring System (CVSS) score of 7.8, this bug, with the foundation for most Linux network firewall and Network Address Translation (NAT) programs, was a nasty little security hole. With it, Netfliter's table component could be exploited to achieve local privilege escalation. 

Worse still, you didn't need to be terribly clever to use it, so a local attacker could escalate privileges from a regular user to root in no time flat. Adding insult to injury, this vulnerability was present in pretty much all the major Linux distributions, including Debian, Fedora, Red Hat, and Ubuntu. In short, pretty much any Linux distribution using any kernel version between 5.14 and 6.6.14 could be hacked.

Ouch!

But, the fix has been in place since January 2024, when the flaw was patched. So, if we've been good little system administrators, we shouldn't have anything to worry about, right? Right!?

Wrong. 

The US Cybersecurity and Infrastructure Security Agency (CISA) has flagged it and added it to the Known Exploited Vulnerabilities (KEV) catalog. It turns out that it's being actively exploited in the wild.

Now, if this were happening back in March, I wouldn't be surprised. That's when the flaw finder, who went by the name Notselwyn, published a CVE-2024-1086  proof-of-concept exploit. He reported that it had a 99.4% success rate on kernel 6.4.16 and provided a detailed technical report. His method, called Dirty Pagedirectory, builds on the earlier Dirty Pagetable technique, allowing unlimited, stable read/write access to all memory pages in a Linux system.

I don't think you need to be a security expert to know that's bad. 

NIST reports that "This vulnerability has been modified and is currently undergoing reanalysis. Please check back soon to view the updated vulnerability summary."

I wonder, though, I really do, whether it's really been updated or whether it's just that there's now a bot toolkit using it. As a result, thousands of automated attempts are discovering that far too many people never patched their Linux machines in the first place. As Hanlon's Razor explains, "Never attribute to malice that which is adequately explained by stupidity.

So, may I suggest you check to see if your distro is still open to the original attack? You can do that by running the command:

$ uname -r

In your terminal. 

If the output of any of these commands shows a kernel version between 3.15 and 6.8-rc1, your system is potentially vulnerable to CVE-2024-1086. For instance, if uname—r returns 5.13.0-39-generic, your system is within the affected range and should be updated.

The patched kernels for the major Linux distros include:

Debian

• Kernel-Version: 6.1.76-1

Ubuntu

• Ubuntu 18.04: 4.15.0-223.235

• Ubuntu 20.04: 5.4.0-174.193

• Ubuntu 22.04: 5.15.0-101.111

• Ubuntu 23.10: 6.5.0-26.26

Red Hat and Red Hat-based distros:

• RHEL 7: 3.10.0-1062.4.1.el7

• RHEL 8: 4.18.0-147.el8

• RHEL 9: 5.14.0-362.24.2.el9_3

SUSE

• There are various fixed kernel versions for the SUSE Linux Enterprise distros.

To be safe, update your systems and then reboot them with the following commands: 

Update Package Lists:

$ sudo apt update  # For Debian/Ubuntu

$ sudo yum update  # For Red Hat/CentOS

$ sudo zypper refresh  # For SUSE

$ sudo dnf update  # For AlmaLinux/Rocky Linux

Upgrade Kernel:

$ sudo apt upgrade  # For Debian/Ubuntu

$ sudo yum update kernel  # For Red Hat/CentOS

$ sudo zypper update  # For SUSE

$ sudo dnf update kernel  # For AlmaLinux/Rocky Linux

Reboot System: 

$ sudo reboot

All should be well.  

But, if you can't patch it or think there may indeed be a new version of the vulnerability out there? In that case, you can mitigate it by disabling the ability for unprivileged users to create namespaces. To do this temporarily, in the Debian/Ubuntu world run:

$ sudo sysctl -w kernel.unprivileged_userns_clone=0

To disable it for once and all:

 echo kernel.unprivileged_userns_clone=0 | \ sudo tee /etc/sysctl.d/99-disable-unpriv-userns.conf

Personally, I've never been keen on granting unprivileged users the ability to create namespaces. As a wise admin once said, "Unless you truly need it, just disable it."

Noteworthy Linux and open-source stories:

• Are all Linux vendor kernels insecure? A new study says yes, but there's a fix

• Winamp is not going open source. Here's what it is doing - and why

• More than money, open-source pros want these 2 things from their next jobs