Security Researchers Create Proof-of-Concept Program that Evades Linux Syscall-Watching Antivirus (theregister.com) 10
Slashdot reader Mirnotoriety shared this report from the Register:
A proof-of-concept program has been released to demonstrate a so-called monitoring "blind spot" in how some Linux antivirus and other endpoint protection tools use the kernel's io_uring interface.
That interface allows applications to make IO requests without using traditional system calls [to enhance performance by enabling asynchronous I/O operations between user space and the Linux kernel through shared ring buffers]. That's a problem for security tools that rely on syscall monitoring to detect threats... [which] may miss changes that are instead going through the io_uring queues.
To demonstrate this, security shop ARMO built a proof-of-concept named Curing that lives entirely through io_uring. Because it avoids system calls, the program apparently went undetected by tools including Falco, Tetragon, and Microsoft Defender in their default configurations. ARMO claimed this is a "major blind spot" in the Linux security stack... "Not many companies are using it but you don't need to be using it for an attacker to use it as enabled by default in most Linux systems, potentially tens of thousands of servers," ARMO's CEO Shauli Rozen told The Register. "If you're not using io_uring then disable it, but that's not always easy with cloud vendors."
That interface allows applications to make IO requests without using traditional system calls [to enhance performance by enabling asynchronous I/O operations between user space and the Linux kernel through shared ring buffers]. That's a problem for security tools that rely on syscall monitoring to detect threats... [which] may miss changes that are instead going through the io_uring queues.
To demonstrate this, security shop ARMO built a proof-of-concept named Curing that lives entirely through io_uring. Because it avoids system calls, the program apparently went undetected by tools including Falco, Tetragon, and Microsoft Defender in their default configurations. ARMO claimed this is a "major blind spot" in the Linux security stack... "Not many companies are using it but you don't need to be using it for an attacker to use it as enabled by default in most Linux systems, potentially tens of thousands of servers," ARMO's CEO Shauli Rozen told The Register. "If you're not using io_uring then disable it, but that's not always easy with cloud vendors."
Good concept bad deployment (Score:1)
Re: (Score:2)
This may be a cultural thing. "Performance" people rarely get security and rarely understand how critical it is. Hence they do things like this.
Get root, do anything... (Score:2)
io_uring can be allowed or denied in SELinux and AppArmor, and it takes root access to take advantage of this exploit. Docker blocks this in the default seccomp profile.
This seems like a tempest in a teacup. A properly running Linux machine isn't going to allow any off the shelf app to run as unconstrained root. A user might, but how many apps are going to be installed as root these days, and not stuffed in a container? However, a malicious app run by root unconstrained can also lodge into a lot of othe
Re: Get root, do anything... (Score:1)
Re: (Score:2)
It's been a universal truth since the first days of Unix that root permissions allow unconstrained access to configure, execute, steal and destroy. Still, the fact is that while secured Linux installs are going to make running such an exploit very hard or even nearly impossible with regular user access, not all systems are secured. I've seen people intentionally reduce or remove security rules to get something running, so there are no lack of improperly secured Linux systems out there.
Re: (Score:3)
This seems like a tempest in a teacup.
My suspicion is that the attention on this is a sales tactic.
ARMO sells security software within a whole category of software Linux users probably don't need.
Ultimate sales tactic for the Endpoint market is to "find" an issue where you can imply your competitors' similar "security" products were bypassed, then put in thousands of hours on a research proof of concept to show that. This makes you 'look' really good, and makes your competitors look not as good, even
Re: (Score:2)
This seems to be what the business plan reminds me of:
1: Look for something like /dev/mem or /dev/kmem, show it can be modified and protections bypassed, even though there are many devices that can be looked at with unfettered/unconstrained root access.
2: Make some kernel module which catches that... or is supposed to. Sell it as added security software. Make sure to get some sort of software patent on it so it doesn't become a part of ClamAV in its next rev.
3: ?????
4: Profit!
Granted, having a signatu
A very powerful, terrifying exploit (Score:5, Informative)
It can also evade the /. dupe detection AI.
https://linux.slashdot.org/sto... [slashdot.org]
Re: (Score:2)
And all the high-rated comments from last time about how the article is alarmist click-bait still apply.
So how is it fixed selectively? (Score:2)
Is there some way to use say selinux to restrict this functionality only to software which you want to have access to it?
It's really too bad Linux systems haven't embraced capabilities based security more, though I can see that Debian has a lot more apparmor profiles than the last time I looked so there is some progress there. As far as I know there's no tools which make configuring that kind of security possible without knowing a whole lot about the internal workings of a program, but it seems like it shou