New Linux Rootkit

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.

Here’s the code.

Note the self-serving nature of this announcement: ARMO, the company that released the research and code, has a product that it claims blocks this kind of attack.

Tags: Linux, rootkits

Posted on April 24, 2025 at 3:35 PM • 8 Comments

Comments

Peter • April 24, 2025 5:21 PM

One simple “fix” is to disable io_uring. In most cases the performance impact will be acceptable.

Auditing and security may have been a bit of an afterthought.

Julia Clement • April 24, 2025 7:07 PM

This was just waiting to happen, if it hasn’t already happened earlier. In June 2023, Google reported on its Security blog:

in the past year, there has been a clear trend: 60% of the submissions exploited the io_uring component of the Linux kernel[…]. Furthermore, io_uring vulnerabilities were used in all the submissions which bypassed our mitigations.
[…]
To protect our users, we decided to limit the usage of io_uring in Google products:

ChromeOS: We disabled io_uring (while we explore new ways to sandbox it).

Android: Our seccomp-bpf filter ensures that io_uring is unreachable to apps. Future Android releases will use SELinux to limit io_uring access to a select few system processes.

GKE AutoPilot: We are investigating disabling io_uring by default.

It is disabled on production Google servers.

I’m sure that there are a small number of use cases where io_uring gives a major benefit, but having it enabled by default on all Linux system seems dangerous to me.

lurker • April 25, 2025 12:03 AM

LWN waved a big red flag four years ago [1], so the only surprise here is that the rootkit is issued in public this much later, and apparently still works.

“there is nobody with a checklist making sure that all of the relevant boxes have been marked before a new subsystem can be merged.”

[1] https://lwn.net/Articles/858023/

Clive Robinson • April 25, 2025 6:37 AM

@ Julia Clement, ALL,

With regards,

“… having it enabled by default on all Linux system seems dangerous to me.”

This is true of all “off device I/O” even the humble serial port (now mostly done by USB). As well as a number of other “on device processes” to do with inter process communications.

In fact just about any function that serialises data is a potential security vulnerability via a side channel, when you dig into it.

So the question is

“What benefit” do such functions have?”

Well anyone who has “bit banged” serial data asynchronous or not out of a microprocessor can tell you “Comms is a lot of work” thus any library or pre-written function “lifts the yoke”.

However standard “Asynchronous IO”(AIO) interfaces on most operating systems that have their roots older than a decade or so have a “traditional” view as to AIO which is “slow and burdensome” and don’t really work well with modern hardware capabilities. As has been observed

“Everything through the kernel twice then block…”

Anyone who has tried writing a terminal program that looks even remotely interactive knows that,

“The POSIX Way is the WRONG way!”

And the same is true for anything that “blocks”.

Yes there are “poll” based functions using “signals” but you really won’t find many who will be happy to do it.

But fundamentally traditional AIO works on the blocking “completion model” rather than a “readiness model”.

Further it uses “circular buffers” that don’t need “signalling flags” as with a little bit of thought the signalling becomes implicit in the read or write functions via the pointer use.

But further… even with well written code most programmers that do various serialisation functions be it bit, byte, or block generally do not realise what awful vulnerabilities they open up in the process.

As a rule of thumb traditional AIO is written in a “conservative” fashion on the assumption programmers “will break the system if allowed to”… Which is all to often true.

They way around much of this for high IO code like web servers has been to move the IO from kernal space to user space as much as possible to get the fineness of control. But you can all to easily end up with deadlocks and resource hog issues, that appear to happen at the worst of times.

The theory is io_uring gets around most of these issues and at the same time cuts down a lot of load from the system.

For those that want to get more into the reasoning,

https://blogs.oracle.com/linux/post/an-introduction-to-the-io-uring-asynchronous-io-framework

The reason io_uring is seen as “less secure” is not that it is (all comms IO is by definition insecure)… But because it’s “not being watched” the same way as other kernel based IO.

That is the fault not of io_uring or it’s designers and developers, but the fault of the “security monitor” software being “blind in one eye” thus “Doing a Nelson” of “I see no ships”.

Clive Robinson • April 25, 2025 7:46 AM

@ ALL,

Due to not immediately being able to find it…

https://m.youtube.com/watch?v=AaaH6skUEI8

Which is why I also left Something out of my above… which is the old “you can have any two of three” comment that applies to io_uring,

“Of speed, ease of use, and oversight, you can have any two…”

Why do I say “oversight” well it’s what allows you to do realtime “audit” like logging of resource usage. Audit in turn allows you to do realtime “control” such as for flow. But logging and control can if you put in the processes give you a measured level of “security”.

In the past “Oversight, audit, Control” and thus security was all done through SysCalls[1] that are very high “overhead”, which for the benefit of speed and ease of use io_uring minimised or removed. Also the SysCall model for IO is by tradition[1] “fast blocking” which is bad news for any kind of server, multi-thredded, or multi-tasking process which is the norm these days (even for users, think about how a web browser actually works).

When you watch the video remember this and realise that io_uring is just the tip of the iceberg to the demise of traditional SysCalls as being “Nolonger fit for purpose”.

[1] SysCalls are grossly inefficient at the best of times and come from a time where CPU speed was only just creeping out of KHz to MHz clock speeds and off device IO was down at the 45-75 baud rate. So having high overhead –providing blocking was fast– was not an issue back then hence the “completion model” rather than a “readiness model” as it increased the speed of process / context switches thus increased the “livelyness” feeling for single process users that was “multiuser” back then (as well as putting CPU count on the user not the kernel so increasing income).

Who? • April 25, 2025 10:33 AM

From this blog entry:

Note the self-serving nature of this announcement: ARMO, the company that released the research and code, has a product that it claims blocks this kind of attack.

In the nineties, a few software companies were caught releasing signatures for virus on their online protection products before the virus themselves were discovered. Nothing changes… the same company that builds the cure makes the illness.

broken butler • April 25, 2025 12:30 PM

It’s sure frustrating trying to post something and reformatting it to try and dodge moderation queue only to constantly be forwarded to the moderation queue!

Unbelievable.

ResearcherZero • April 26, 2025 2:40 AM

You could disable it when you compile the kernel, which you do of course because you want to reduce the attack surface of production machines and probably don’t need it anyway?

io_uring apparently gets a lot of vulnerability submissions so it would be a good idea.

‘https://www.phoronix.com/news/Linux-6.6-sysctl-IO_uring

Operating systems have lots of dumb privilege escalation vulnerabilities or other methods that can be used to break things or prevent parts of the system from functioning even without DOGE or Microsoft installing things willy-nilly with little thought, then installing something else to fix what was broken in an attempt to fix the last screw up.

‘https://www.bleepingcomputer.com/news/microsoft/windows-inetpub-security-fix-can-be-abused-to-block-future-updates/

New Linux Rootkit

Comments

Leave a comment Cancel reply