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.
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?
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!
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.
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.
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.
Yep. Usually at application startup, shaders are compiled. Later in your renderer code you bind that shader just before you want to draw something using it.
On the other hand, these GPU computing codes are so damned complex they might not need additional obfuscation.
Not necessarily. Shaders can be very simple as well. They usually range from some tens to some hundreds of lines. Check out Shadertoy to see some.
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
It's the end of the world!
I feel fine.
Jesus was all right but his disciples were thick and ordinary. -John Lennon
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.