Nasty Linux netfilter firewall security hole found:
Behind almost all Linux firewalls tools such as iptables; its newer version, nftables; firewalld; and ufw, is netfilter, 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.
Nick Gregory, a Sophos threat researcher, found this hole recently while checking netfilter for possible security problems. 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.
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]), giving full local privilege escalation, container escape, whatever you want." Yuck!
[...] 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), and with a Common Vulnerability Scoring System (CVSS) score of 7.8), this is a real badie.
How bad? In its advisory, Red Hat said, "This flaw allows a local attacker with a user account on the system to gain access to out-of-bounds memory, leading to a system crash or a privilege escalation threat." So, yes, this is bad.
(Score: 2) by hopdevil on Thursday March 24 2022, @05:07AM (8 children)
(Score: 1, Offtopic) by Mojibake Tengu on Thursday March 24 2022, @06:42AM (1 child)
What about unprivileged containers, those safe by design can artifice this stunt pretty mischievous.
Rust programming language offends both my Intelligence and my Spirit.
(Score: 1, Troll) by hopdevil on Thursday March 24 2022, @07:06AM
This has nothing to do with containers.. this issue trumps any container security model
(Score: 0) by Anonymous Coward on Thursday March 24 2022, @06:47AM (2 children)
Disabling offload doesn't effect the ability to exploit this bug based on where it is. However, this bug isn't completely terrible without it. For one thing, the chances of succeeding are not 100%. Based on the tests I've seen, about 50% of attempts panic and another 20% cause corruption without successful escalation, which is its own problem and actually makes repeated attempts at using the exploit harder. The remaining percentage did successfully escalate privilege but may have also caused other collateral issues to make detection or other negative outcomes more likely even when it "works."
(Score: 2) by hopdevil on Thursday March 24 2022, @07:00AM (1 child)
Detection if it works is less of a concern when thinking about the exploitability, no bug is perfect.. but I'm sure some group of people would love to know what "signatures" it leaves. Repeated attempts and sometimes/most times completely crashing out kernels randomly is guaranteed to raise some eyebrows. But hell, how many actually monitor their servers that closely anyway
(Score: 0) by Anonymous Coward on Thursday March 24 2022, @09:12AM
I'm not sure how closely most people watch their servers, but I would hope that panics would get some part of their attention. But it is also a basic fact that some percentage of people do seem to fire and forget or somehow lose track of their machines. A side benefit of this bug, as long as those using it don't get the success rate up, is that it might just reduce the number of zombies out there.
(Score: 5, Insightful) by driverless on Thursday March 24 2022, @08:16AM (1 child)
It's also not that bad:
If you're using netfilter in a firewall and an attacker has a local account on your firewall then you've already lost. I'm not saying that a local privesc isn't bad, but if the attacker has already got through your firewall then it's pretty much game over.
(Score: 0) by Anonymous Coward on Thursday March 24 2022, @12:16PM
aren't most exploits about privilidge escalation from userland? so it is only bad when a known exploit exists. or are you saying all user credentials should have to promise ther are not an attacker to use your system?
(Score: 0) by Anonymous Coward on Thursday March 24 2022, @12:46PM
The exploit talks to netlink and inserts the offload rule to trigger the exploit; the modules need to be loaded there doesn't need to already be an offload rule. A "normal" unprivileged user is not able to talk to netlink so it should only be exploitable by root but for the new container support that lets a non-privileged user create a new container/namespace (via unshare) and be uid 0 in that namespace. The workaround is to disable user namespace support (echo 0 > /proc/sys/user/max_user_namespaces).
(Score: 2, Interesting) by Anonymous Coward on Thursday March 24 2022, @12:26PM (2 children)
You can get it here [openbsd.org]
(Score: 1, Informative) by Anonymous Coward on Thursday March 24 2022, @12:31PM
Amusing, but the fix is actually already out. In fact if you get the fix from last week's security hole, you'll get the fix for this one included at no extra charge.
(Score: 2) by bart9h on Thursday March 24 2022, @12:58PM
I was about to smugly post how I'm not worried as my server runs OpenBSD.
(Yet my desktop runs Linux, but it does not use iptables, nor it is infected by systemd.)
(Score: 2) by ledow on Thursday March 24 2022, @02:28PM (1 child)
"local attacker with a user account on the system"
So... a malicious user who is already authenticated on your system.
In the scope of problems that something like netfilter could have, that's at the tamest end.
(Score: 0) by Anonymous Coward on Friday March 25 2022, @01:19AM
I've never had a co-worker have their computer compromi... uuhh... uuhh... yet this week.
(Score: -1, Flamebait) by Anonymous Coward on Thursday March 24 2022, @07:36PM (1 child)
"This vulnerability is present in the Linux kernel versions 5.4 through 5.6.10"
what fucking decade do you people think this is? my out-of-date server is running 5.12
(Score: 2) by drussell on Thursday March 24 2022, @11:47PM
Some people run LTS release and whatnot, often for good reasons.