An Israeli vendor was able to evade several leading Linux runtime security tools using a new proof-of-concept (PoC) rootkit that it claims reveals the limitations of many products in this space.
The work of cloud and Kubernetes security company Armo, the PoC is called ‘Curing’, a portmanteau word that combines the idea of a ‘cure’ with the io_uring Linux kernel interface that the company used in its bypass PoC.
Using Curing, Armo found it was possible to evade three Linux security tools to varying degrees: Falco (created by Sysdig but now a Cloud Native Computing Foundation graduated project), Tetragon from Isovalent (now part of Cisco), and Microsoft Defender.
Falco was blind to Curing, while Defender was unable to detect either Curing or a range of other common malware. Tetragon, on the other hand, was able to detect io_uring, but only when using Kprobes and LSM hooks, which Armo said are not used by default.
According to Armo, the problem with all three is an over-reliance on Extended Berkeley Packet Filter (eBPF) based agents, which monitor system calls as a simple approach to gaining visibility of threats. Despite the benefits of this, not everyone in the industry thinks this is a good design.
“System calls aren’t always guaranteed to be invoked; io_uring, which can bypass them entirely, is a positive and great example. This highlights the trade-offs and design complexity involved in building robust eBPF-based security agents,” wrote Armo’s Head of Security Research, Amit Schendel.
The io_uring approach is a blind spot eBPF tools couldn’t detect, he noted. “This mechanism allows a user application to perform various actions without using system calls. As a result, security tools relying on system call monitoring are blind to rootkits working solely on io_uring.”
Long list of CVEs
The io_uring API has been in Linux since version 5.1 in 2019, when it was added to overcome the problem of inefficient asynchronous or ‘non-blocking’ I/O performance in the existing native AIO (libaio) library.
In essence, programs can submit multiple I/O requests to the kernel via an intermediate stage called a ring buffer. This allows the application to do something else while it waits for the I/O operation to complete.
The downside is that io_uring can act like a highway into the kernel which can be abused, as demonstrated by Armo’s Curing rootkit. The danger of this is attested to by the steady number of CVE-level flaws in the io_uring interface since its appearance.
Armo said it was motivated to create the rootkit to draw attention to two issues. The first was that, despite the io_uring technique being well documented for at least two years, vendors in the Linux security space had yet to react to the danger.
The second purpose was to draw attention to deeper architectural challenges in the design of the Linux security tools that large numbers of customers rely on to protect themselves:
“We wanted to highlight the lack of proper attention in designing monitoring solutions that are forward-compatible. Specifically, these solutions should be compatible with new features in the Linux kernel and address new techniques,” said Schendel.
In other words, to achieve better Linux security, software should anticipate new attacks rather than constantly tweaking its design after the fact.
How have vendors responded?
This, perhaps, is Armo’s key point: the slow pace of change and claimed relaxed response by Linux security vendors to the issue of kernel security.
When contacted by Armo, Falco’s maintainers acknowledged the issue with the software and said they were working on a plugin that would offer better visibility.
Armo had less success with Microsoft. “Unfortunately,” said Schendel, “Microsoft was unresponsive despite multiple attempts on our part to reach out and engage with them.” .
And Isovalent, he wrote, told Armo that Tetragon was not vulnerable because it provided the “flexibility to hook basically anywhere.”
Isovalent reiterated the same point in comments to this publication, disputing Armo’s claim that Tetragon was reliant on system calls:
“Tetragon doesn’t ‘rely on syscall monitoring’ as suggested in the Armo blog,” said Isovalent Chief Open Source Officer, Liz Rice. “Tetragon provides the option to use syscalls, but it can use eBPF to hook into many other areas of the kernel too, including the Linux Security Module API.”
“This is a much more robust approach for detecting security-relevant events such as file access — including access via io_uring,” she said, adding, “one of the advantages of Tetragon is that it filters events in-kernel, so that instead of reporting a firehose of all file access events, only those defined as sensitive by the policy are generated. This filtering allows Tetragon to provide runtime security at very little overhead.”
Rice has also posted a YouTube video to back up her point.
Notably, the open source projects (Falco, Tetragon) responded to Armo’s contact regarding its Curing PoC, while the proprietary software representative (Microsoft) didn’t. This could, of course, simply reflect the size disparity of the organizations involved.
The obvious caveat with Armo is that its claims about deficiencies in other products help to market its own run time Linux security platform which, naturally, doesn’t suffer from the same issues. However, it did suggest some detection strategies for other security vendors, including advocating implantation of kernel runtime security instrumentation (KRSI).
At the very least, it said, Linux software should look to monitor for unusual usage in the io_uring interface.
“For instance, if an application that has historically never used io_uring suddenly begins leveraging it, that’s a clear red flag,” wrote Armo’s Schendel.
The original article found on SAP NetWeaver customers urged to deploy patch for critical zero-day vulnerability | CSO Online Read More
