Hackers Can Now Bypass Linux Security Thanks To Terrifying New Curing Rootkit (betanews.com) 36
BrianFagioli writes: ARMO, the company behind Kubescape, has uncovered what could be one of the biggest blind spots in Linux security today. The company has released a working rootkit called "Curing" that uses io_uring, a feature built into the Linux kernel, to stealthily perform malicious activities without being caught by many of the detection solutions currently on the market.
At the heart of the issue is the heavy reliance on monitoring system calls, which has become the go-to method for many cybersecurity vendors. The problem? Attackers can completely sidestep these monitored calls by leaning on io_uring instead. This clever method could let bad actors quietly make network connections or tamper with files without triggering the usual alarms.
At the heart of the issue is the heavy reliance on monitoring system calls, which has become the go-to method for many cybersecurity vendors. The problem? Attackers can completely sidestep these monitored calls by leaning on io_uring instead. This clever method could let bad actors quietly make network connections or tamper with files without triggering the usual alarms.
Optional kernel feature? (Score:4, Informative)
io_uring is an optional kernel feature, which you can turn off or compile out if you're not using...
Re:Optional kernel feature? (Score:5, Informative)
Most people don't tune their kernels, much less compile them. The question is, is it turned on in the stock kernel of the distro you're using?
Of course, if it is, this being made public mean it won't be for long. If you do your updates, I'd expect you'd be fine.
Re:Optional kernel feature? (Score:5, Informative)
Also.. Linux "Security" is Not 3rd party antimalware programs that monitor syscalls.
No Linux security has been defeated by the existence of the rootkit. Security was defeated when an intruder gained root.
Security is the kernel's permissions and access control models. Things like non-root processes not having access to execute privileged operations.
It sounds like the only thing that has been bypassed are EDR programs; tools such as Crowdstrike, Palo Alto Cortex, Microsoft Defender, Carbonblack, SeintnelOne which are not Linux security but Enterprise tools which attempt to monitor Linux systems.
Linux security modules do depend on it (Score:5, Interesting)
SELinux, a Linux security feature, depends heavily on monitoring system calls. The whole Linux security module system is largely based around monitoring system calls. It seems they didn't consider providing a mechanism for security modules to monitor io_uring for nefarious activity.
Re: (Score:3)
If io_uring requires root then this is a nothingburger.
Raymond Chen, Microsoft developer, uses the phrase "It rather involved being on the other side of this airtight hatchway" to refer to such "exploits".
Re:Optional kernel feature? (Score:5, Informative)
The linked article is very light on details. I did a little searching around and it appears that one does, in fact, need root in order to set up io_uring, though it can also be done with sudo, and it looks like it is possible to set things up so it can subsequently be used for specific operations without root (though I am unsure about that).
Apparently this isn't actually news, as the library has been under criticism for this sort of thing for a while. Some distributions, such as Ubuntu, don't use it by default, so you would have to go out of your way to set that up in those cases.
Though my knowledge here is only as good as what I found in a few blog posts as I was searching around, so please feel free to correct me.
Re:Optional kernel feature? (Score:5, Informative)
To understand this, you need to take a step back and remember that root is a blunt instrument, but one you need to use frequently. This is why we have things like SELinux to give more fine-grained control over what things running as root can do.
Consider a mail delivery agent. It needs to run as root because it has to be able to change uid/gid to the user that it's delivering mail for to access their mailbox, and that's something only root can do. But this is bad, because it means a but in the mail delivery agent could be exploited to anything root can do.
So to mitigate this, we create an SELinux policy that says the only thing the mail delivery agent can do while running as root is read its configuration, accept a connection from the MTA, and switch to a non-root user/group. We create another policy that while running as a non-root user, the mail delivery agent is only allowed to access directories and files labelled as "user mailbox" content. (This is over-simplified, but you get the idea.) This greatly mitigates what an exploit can do. Now all it can do is impersonate a user and corrupt their mail. It can't even easily exfiltrate their mail, as it can't make connections or copy it to another location.
The vulnerability here is that SELinux (and other Linux security modules) can't monitor what a process does via io_uring. So in this example, if the mail delivery agent is allowed to create an io_uring, an exploit may gain the ability to read/write any file/device and make network connections, and SELinux won't be able to stop it. This makes mitigations a lot less effective.
This has been known since at least 2023. Android doesn't allow apps to use io_uring, ChromeOS has io_uring disabled completely, Docker doesn't allow use of io_uring from inside containers, and I think Ubuntu might have io_uring disabled by default, too.
Now io_uring is useful and can give a big performance improvement, but mostly for processes that fall into a few categories: doing a lot of I/O, managing large numbers of network connections, and requiring low end-to-end latency. This is generally stuff like database servers, real-time streaming services (video streaming, telephony), electronic trading when you have a fast connection to the exchange, etc. You aren't likely to be running a lot of this stuff on your desktop.
The article and the summary are alarmist clickbait. It's basically a known issue, but the mitigation of not allowing io_uring for the majority of processes is probably viable for most people.
Re: (Score:2)
and I think Ubuntu might have io_uring disabled by default, too.
Eh?
Linux s1 6.8.0-57-generic #59-Ubuntu SMP PREEMPT_DYNAMIC Sat Mar 15 17:40:59 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux /boot/config-$(uname -r)
root@s1:~# lsb_release -sd
No LSB modules are available.
Ubuntu 24.04.2 LTS
root@s1:~# grep URING
CONFIG_IO_URING=y
root@s1:~# sysctl -a|egrep uring
kernel.apparmor_restrict_unprivileged_io_uring = 0
kernel.io_uring_disabled = 0
kernel.io_uring_group = -1
This has been known since at least 2023. Android doesn't
Re: (Score:2)
If io_uring requires root then this is a nothingburger.
Raymond Chen, Microsoft developer, uses the phrase "It rather involved being on the other side of this airtight hatchway" to refer to such "exploits".
That follows, pretty stereotypically, exactly how one might expect a Microsoft developer to reason. But, in practice, that "airtight" hatchway is surprisingly leaky - local privilege escalation exploits exist as well, and pop up regularly. So it just means a remote attacker needs to take advantage of two (or more) vulnerabilities to get at this - a remote access exploit followed by local privilege escalation. And, if you've paid attention over the past decade or more, you'll know the bad guys are used to do
Re:Optional kernel feature? (Score:5, Informative)
It seems that in Debian testing at least it is present:
grep -i uring /boot/config-$(uname -r)
CONFIG_IO_URING=y
Re:Optional kernel feature? (Score:5, Informative)
It's also enabled in Ubuntu 24.04.2 LTS' kernel 6.8.0-57-generic.
Re: (Score:3)
Yeah, so if there is indeed a rootkit going around and if it does what it is claimed, it probably makes sense to recompile without it.
I'll read up on it later to decide how "terrifying" this new scourge is, TFS is a bit unclear on what's going on.
Re:Optional kernel feature? (Score:5, Informative)
The "rootkit" mentioned in TFA is just a proof of concept demonstrating that you can use io_uring to avoid being monitored by Linux security modules like SELinux or AppArmor. It isn't being used by malware in the wild.
The trouble with disabling io_uring is that you'll get a pretty substantial performance hit in applications that actually use it. The Linux AIO API was basically broken. It only worked on files, only on portions of files that are already allocated, and in many situations an operation would unexpectedly become synchronous. The io_uring API was created to solve these issues. Things like databases or services that manage large numbers of network connections benefit substantially from io_uring. You could end up needing more servers to handle the same load as well as getting poorer end-to-end latency with it disabled.
Re:Optional kernel feature? (Score:4)
Yeah, apparently it is so; hence one has to first check if something they need is using it, assess the risks and benefits of leaving it on (which to me isn't a straightforward thing to do right away) and then to consider what measures to take, if any, to alleviate those risks.
Someone posted a link to an informative article from 2022, but it is hard to see how much of it applies today, as it seems some things were done to mitigate the issues since then.
So I guess now that everyone and their dog is aware of the potential problem, we'll see the followup on LKML and then try to figure out what to do. As you say, this doesn't appear to be the immediate risk the word "terrifying" in the TFS is implying.
Re: (Score:2)
Correct, that part's just clickbait bullshit.
Re: (Score:1)
Alright, I'll cut right to the chase. What's the chances any video games actually need this thing for performance? If I'm just running a regular desktop for basic productivity, communication and entertainment tasks, not like a web or database server, do you think it's safe to disable out of an abundance of caution?
Re: (Score:2)
Ah, I see you've answered that second question in your above post and it appears this isn't some sort of active exploit. Oh, well...
Re: (Score:3)
It's also enabled by default in Mint 21.3.
How does one turn this off, and should it be turned off or disabled?
Re: (Score:3)
Recompile the kernel from sources with your current config (/boot/config-`uname -r`) and have just that option in the new .config set to "n" is the most straightforward way, I guess.
Re:Optional kernel feature? (Score:4, Informative)
But, as others have pointed out, perhaps this would be an unnecessary overreaction at present.
Re:Optional kernel feature? (Score:4, Informative)
From what I can see, Slackware has it compiled in:
cd /usr/src/linux-5.15.161/
grep CONFIG_IO_URING .config
CONFIG_IO_URING=y
Re:Optional kernel feature? (Score:5, Informative)
Google and others already turn off io_uring. io_uring is not available to apps in android, it's off entirely in ChromeOS and off on Google's own servers. Docker blocks io_uring calls by containers (by default) as well.
Re: Optional kernel feature? (Score:2)
The other solution might be to turn it off when building everything but the most trusted applications. If you've got a performance critical database, go ahead and build the dbms system with it. For stuff like mystery apps you grab off the Internet, or apps that can pull in scripts and stuff, turn it off in their build.
2022 article on io_uring security (Score:5, Informative)
From Security requirements for new kernel features [lwn.net], Jonathan Corbet, July 28, 2022:
"A recent discussion about security hooks for the new uring_cmd mechanism shows how easily requirements can be overlooked in a complex system with no overall supervision."
[Corbet quoting from another source]
"You're passing the complexity of uring-cmd directly into each and every security module. SELinux, AppArmor, Smack, BPF and every other LSM now needs to know the gory details of everything that might be in any arbitrary subsystem so that it can make a wild guess about what to do. And I thought ioctl was hard to deal with."
There's more there and elsewhere [wikipedia.org].
Re: (Score:2)
this should be modded up, it is a lot more useful than the TFS, if a bit old.
if it is compiled as a module (Score:2)
This was intentional. And not just linux. (Score:1)
This also impacts Windows as WSL is used to leverage the ubuntu Linux kernel that also has this enabled, intentionally.
Imagine the power they have over your Windows machine by having root control of a Windows kernel running on your machine that's loading a Linux kernel that they have full control over.
O'RYL? (Score:4)
So I can bypass Linux security by hiding inside an SSL channel?
A blindspot in 3rd party monitoring software is NOT a security bypass. It is a deficiency in the monitoring software.
The world has changed. Tripwire and Clam-AV are not adequate protections, if they ever were.
Re: (Score:3)
Awww, come on, didn't you get immediately scared when you saw "terrifying" and "root kit" in the summary :)
Re: (Score:3, Funny)
I'm shaking in my reboots.
Re: O'RYL? (Score:2)
I never get worked up about anything mentioning "root kit". If you've gotten a root kit onto my machine, it's game over anyway.
Huh. (Score:4)
Why are they monitoring syscalls?
The correct solution is surely to use the Linux Kernel Security Module mechanism, as you can then monitor system functions, regardless of how they are accessed. All system functions, not just the ones that have provision for tracepoints.
For something like security software, you want the greatest flexibility for the least effort, and Linux allows you to do just that.
Because it's fine-grained, security companies can then pick and choose what to regard or disregard, giving them plenty of scope for varying the level of detail. And because the LSM allows services yo be denied, there's a easy way for the software to stop certain attacks.
But I guess that the obvious and most functional approach would mean that the vendors would have to write a worthwhile product.
Odd strange and bizarre (Score:4)
The link is to an article talking about a vendor product.
No normal source of information about this bug is talking about it anywhere.
If it were genuine and important, we'd already have gotten word about this and bug fixes in our distro
s updates.
For now it's on ignore as far as i'm concerned.
Re: (Score:2)
That's not always true. It's not uncommon for info about bad vulnerabilities to get embargoed until patched, and we've also seem attention-seeking dolts prematurely break such embargoes before.
Note that I'm not claiming that's what happened here.