Slashdot Mirror
Proof-of-Concept Linux Rootkit Leverages GPUs For Stealth
itwbennett writes: A team of developers has created a rootkit for Linux systems that uses the processing power and memory of graphics cards instead of CPUs in order to remain hidden. The rootkit, called Jellyfish, is a proof of concept designed to demonstrate that completely running malware on GPUs is a viable option. Such threats could be more sinister than traditional malware programs, according to the Jellyfish developers, in part because there are no tools to analyze GPU malware, they said.
...my Rage XL in my otherwise-headless server, will it?
Do not look into laser with remaining eye.
It's the end of the world!
Recently it was discovered that certain GPUs can be manipulated to create a radio antennae via internal circuitry. Combine this with a relatively unmanaged kernel on the GPU to create silent malware and a peer-to-peer radio-communicating botnet
If Malware can do it, so can legitimate-ware, perhaps? Emergency tasks can run on cpu-pegged systems, like maybe Windows Task Manager, if they were designed to run on the GPU instead of the CPU?
Don't worry Microsoft already has this feature built-in for any system running more than 8GB of RAM. It's called Windows.
Really, there's no reason to single this out as Linux. It could be done to any OS. I would imagine the first ones we see in the wild will target Windows.
Everyone knows there are no working video drivers on Linux!
I've looked at the code, and all what it does, is storing buffer inside GPU. And when asked, it pickups the buffer and tries to run it...
From my perspective, it's as usefull as storing instructions in some file in the filesystem - presumably the executable itself, and then running it...
I don't see point. It still needs application to run, it cannot just run on the GPU itself.
There's no mention of IOMMU devices in the article. An IOMMU is like an MMU for the I/O; it remaps the memory access of any DMA device to a different area of physical memory, so that:
*The DMA device can't misbehave, as in the article
*A virtual machine can work directly with that DMA hardware device
*The I/O device can be remapped to a memory region it might not otherwise support (e.g. a 6GB offset, from a 32-bit PCI card)
But, the article doesn't say anything about IOMMUs. Does an IOMMU help at all against this vector? Does it completely block it, or only make the attacks slightly harder? Do modern computers, which mostly have IOMMUs available, make use of their IOMMUs to mitigate this at all?
I'd be grateful if anyone knew more about this.
My understanding of GPU coding environment (not as a programmer, thank God, I just listened to job applicants and their presentations) is that, it is quite limited, almost all interpreted code. Some strange combination of C like code being written and then passed to renderers and shaders. It gets kind of "compiled" in place and gets executed. The binary code obfuscation that could be done in a plain regular chipset is generally not possible for GPU. So the source code of the malware itself might be visible to the analysts if they are looking for it. On the other hand, these GPU computing codes are so damned complex they might not need additional obfuscation.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
there are no tools to analyze GPU malware
Does that explain the Radeon drivers then?
This is newsworthy? All it does is hide the original syscall pointers in the GPU. The hook code still needs to be visible to the CPU. pointless/10. 1995 called and their rootkits back.
The rootkit, called Jellyfish, is a proof of concept designed to demonstrate that completely running malware on GPUs is a viable option.
Umm...especially now when you released a base for blackhats to build upon.
...because on Windows, you can't run rootkits; you'd have to run Appkits!
Apps!
You have to have OpenCL drivers installed and up and running for this to affect you. So this will only affect a fraction of linux installations.
Here's a post from 10 years ago about a program that can turn your display into a radio transmitter. I think that the provided code plays a midi version of Beethoven's Fur Elise, but there are variations that play any mp3.
Just to be clear: this works by calculating the pixelclock then using high/low (white/black) swings to generate Electro-Magnetic signals at the corresponding frequencies. I remember running this on an old 300MHz PII Thinkpad. It transmitted through the VGA port and could easily be picked up on portable radio 5 feet away without any antenna
This was a bit of a reverse proof of concept for the NSA's Tempest project. Tempest listened to EM noise and tried to reconstruct what was on the screen (or in the chip / whatever). This demo crafted a display resolution/image such that tones were the EM byproduct
This isn't really that scary as it won't survive a cold re-boot:
"Malicious memory may be retained across warm reboots. (Did more conductive research on the theory of malicious memory still being in gpu after shutdown)"
If you've properly secured your system this shouldn't be an issue. There are more serious threats than this. To get rid of the malware a simple cold boot plus OS reload should fix it. Most of the time people only even know they are infected because the malicious party has done a sloppy job coding the malware or it is otherwise interfering with the operation of the system.
This has been around for a long time. It's a great attack vector against VMware.
... if it can install drivers for this bloody gpu.
my android mobile phone has a GPU. i wonder if it could be made to make free phone calls or unlimited data?
They get really pissy when you mess with their GPU backdoors
-- Tigger warning: This post may contain tiggers! --
Please, make sure you have all the drivers installed to be able to be vulnerable to this rootkit LOL
Please correct me if I am wrong.
I looked through the code, it is not doing any form of hooking of system calls into the GPU to be directly called without it being known. What it does do is call out to the GPU to xor specific strings into a buffer stores on the GPU to hide it's log file. As far as I can tell, the syscall[x].syscall_func is simply a pointer to a GPU function to call which only has access to GPU memory. this is why in each of the "hooked" functions it has to transfer the data to be handled into the GPU. I don't see anything where direct memory access of the CPU is occurring by the GPU without there being a transfer from CPU to GPU.
More like it being easier to quantify everything on an open system than one with obfiscated black boxes, a need for researchers to sign NDAs, or a worry that any criticism of security of a closed platform is going to put you into deep shit via the DMCA (eg. Adobe VS Dmitry S. - no bail!).
They can follow the thread in linux and know what is going on at every step and tell everyone what is going on at each step. With MS there's at least going to be red tape in the way if not a lot of other things.
Assuming proper video driver.
I think "assuming" is the keyword here.
Now you add on top of that the IOMMU and it becomes impossible for the device to access something that have not been mapped
IOMMU ? You mean that thing that Nvidia's engineer don't give a damn about because it won't bring them extra 2fps in benchmarks of Crysis 4 ?
Yup in a theoretical beautiful world, such exploit shouldn't be doable.
(And indeed, such protection has been added against other similar attacks: DMA attacks aren't possible anymore over Firewire, for example).
But, in practice:
- Currently, Nvidia produces closed source drivers only for Linux (except helping a bit Nouveau for Tegra...) They do this by more or less recompiling the Windows drivers which are more or less exclusively performance oriented.
They aren't even able to properly use features that Linux offers differently than Windows (no KMS, no DMA-BUF - though that one is finally moving), they don't support Optimus (it required Linus publicly throwing a FU to get them moving a bit in that direction), texture corruption that happen randomly on laptops (sorry guys, Nvidia mostly test their driver for *Workstations* under linux), and according to industry insiders they don't even properly follow standards such as OpenGL (and thus code heavily optimized for Nvidia - with the help of their embed engineers - tends to barf on anything following OpenGL ?)
And you hope that they'll implement proper security memory protection ?
You can keep dreaming.
- AMD are completely under staffed, and can barely pull a good Linux driver together. Yup in the long term, as they are moving more and more functionnality out of their closed source catalyst, and share more and more with the opensource dirvers, such kind of protection could be doable.
(The long term plan for AMD, is that "Catalyst" will be just an alternative closed source OpenGL implementation that runs over the same stock open-source kernel driver as the free Mesa/Gallium. Thus any memory management and protection handled by the kernel will automatically benefit them).
But that's not the case - yet.
Until AMDGPU kernel derivers matures enough and gets proper IOMMU support, you're still stuck with the exploitable bugs.
(But at least: thank you AMD for working in the correct direction, thank you for having opensource devs on your payroll).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Saddly, the reality is that unlike other similar situation (it's not possible to do DMA attack on firewire anymore), IOMMU aren't yet much used by the binary proprietary drivers.
Nvidia is mostly interested in having good performance. They won't lose resources with things that won't directly influence benchmark results.
AMD is completely understaffed, so don't count on them neither (at least not before they finish the transition to AMDGPU kernel drivers, and until the opensource community add proper IOMMU support in them).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]