{"id":28025,"date":"2022-03-15T20:02:08","date_gmt":"2022-03-15T20:02:08","guid":{"rendered":"https:\/\/rbsitsoftwaresolution.com\/blog\/nasty-linux-netfilter-firewall-security-hole-found.html"},"modified":"2022-03-15T20:02:08","modified_gmt":"2022-03-15T20:02:08","slug":"nasty-linux-netfilter-firewall-security-hole-found","status":"publish","type":"post","link":"https:\/\/www.rbsitsoftwaresolution.in\/blog\/nasty-linux-netfilter-firewall-security-hole-found.html","title":{"rendered":"Nasty Linux netfilter firewall security hole found"},"content":{"rendered":"

Behind almost all Linux firewalls tools such as iptables<\/a>; its newer version, nftables<\/a>; firewalld<\/a>; and ufw<\/a>, is netfilter<\/a>, which controls access to and from Linux’s network stack. It’s an essential Linux security program, so when a security hole is found in it, it’s a big deal.\u00a0<\/p>\n

Nick Gregory, a Sophos<\/a> threat researcher, found this hole recently while checking netfilter for possible security problems<\/a>. Gregory explains in great detail his bug hunt, and I recommend it for those who want insight into finding C errors. But, for those of you who just want to cut to the chase, here’s the story.<\/p>\n

This is a serious bug. Specifically, it’s a heap out-of-bounds write problem with the kernel’s netfilter. Gregory said it’s ” exploitable to achieve kernel code execution (via ROP [return-oriented programming])<\/a>, giving full local privilege escalation, container escape, whatever you want.” Yuck!<\/p>\n

This problem exists because netfilter doesn’t handle its hardware offload feature<\/a> correctly. A local, unprivileged attacker can use this to cause a denial-of-service (DoS), execute arbitrary code, and cause general mayhem. Adding insult to injury, this works even if the hardware being attacked doesn’t have offload functionality! That’s because, as Gregory wrote to a security list, “Despite being in code dealing with hardware offload, this is reachable when targeting network devices that don’t have offload functionality<\/a> (e.g. lo) as the bug is triggered before the rule creation fails.”<\/p>\n

Also: The best Linux distros for beginners: You can do this!<\/a><\/strong><\/p>\n

This vulnerability is present in the Linux kernel versions 5.4 through 5.6.10. It’s listed as Common Vulnerabilities and Exposures (CVE-2022-25636<\/a>), and with a Common Vulnerability Scoring System (CVSS) score of 7.8), this is a real badie.\u00a0<\/p>\n

How bad? In its advisory, Red Hat <\/a>\u00a0said, “This flaw allows a local attacker with a user account on the system to gain access<\/a> to out-of-bounds memory, leading to a system crash or a privilege escalation threat.” So, yes, this is bad.<\/p>\n

Worse still, it affects recent major distribution releases such as Red Hat Enterprise Linux (RHEL) 8.x; Debian Bullseye<\/a>;\u00a0Ubuntu Linux<\/a>, and SUSE Linux Enterprise 15.3<\/a>. While the Linux kernel netfilter patch<\/a> has been made, the patch isn’t available yet in all distribution releases.<\/p>\n

If you don’t have a patch yet, you can mitigate the problem in the RHEL family with the commands:<\/p>\n

# echo 0 \/proc\/sys\/user\/max_user_namespaces<\/p>\n

# sudo sysctl –system<\/p>\n

And, in the Debian\/Ubuntu family with the command:<\/p>\n

$ sudo sysctl kernel.unprivileged_userns_clone=0<\/p>\n

So, here we are again. I’ve not seen a good exploit of this, but I have seen one that works about half the time. If you don’t want to see your Linux servers stolen out from underneath you or just knocked off the net, it’s time to either patch your system or lock it down to avoid trouble.<\/p>\n

See also<\/strong><\/p>\n