Slashdot Mirror
GPU Malware Can Also Affect Windows PCs, Possibly Macs
itwbennett writes: A team of anonymous developers who recently created a Linux rootkit that runs on graphics cards has released a new proof-of-concept malware program that does the same on Windows. A Mac OS X implementation is also in the works. The problem the developers are trying to highlight lies not with the operating systems, such as Windows or Linux, nor with the GPU (graphics processor unit) vendors, but rather with existing security tools, which aren't designed to scan the random access memory used by GPUs for malware code.
I question why anyone would go that route for writing malware. When you start using the OpenCL APIs, your graphics cards will clock up and leave their low power states. The graphics card resource utilization (compute, memory transfers, memory usage) is shown by monitoring tools such as GPU-z and command line tools such as nvidia-smi. You can't hide anything on the GPU.
--- Eat my sig.
The linux rootkit doesn't "run on GPUs". ... you can store data in RAM.
It allocates a buffer on the GPU and then stores strings in that buffer.
So they've demonstrated that
Whoop-dee-fucking-doo.
The are lots of OSs in your computer that are hacked already. The wireless keyboard software or the wifi modem, or the ethernet card software running there. Even on an Apple HDMI *CABLE*, there was an ARM chip (doing re coding) that happens to be upgradeable, i.e. hackable by malware. The vendors leave the OS flashable since it might need a bug fix later, but in doing so they leave it exposed to malware.
Apples HDMI cable is an ARM chip that can be 'upgraded':
http://www.theverge.com/2013/3/1/4055758/why-does-apples-lightning-to-hdmi-adapter-have-an-arm-computer-inside
Phone SIM Card OS hacked, yes the sim card even has an OS:
http://www.extremetech.com/computing/161870-the-humble-sim-card-has-finally-been-hacked-billions-of-phones-at-risk-of-data-theft-premium-rate-scams
The modem in the OS hacked:
http://www.extremetech.com/computing/170874-the-secret-second-operating-system-that-could-make-every-mobile-phone-insecure
1) It's misleading. The code is not executing on the GPU, it's just stored there.
2) It's obvious. If you're just storing code as data, it doesn't matter what OS you use to do that.
3) It's blatant pandering to media. Two stories (at least) on this, no extra content besides the bleeding obvious.
4) It's a symptom of stupidity. If your only safety comes from being able to scan RAM or storage devices and find a "signature" amongst them of a known virus, you're an idiot. It's a stupid, pointless waste of time and computing resources. That there's an area of RAM available that DOESN'T have live protection built into existing antivirus is not shocking at all. Hell, you could store string stuff in the TPM chip, or in the HPA of a hard drive, or in an onboard EEPROM or anywhere else that antivirus can't scan. They'll be unable to "certify" it as safe (as if they could anyway!) and will have to rely on somehow spotting the loader program before execution no matter what variant of it is used, or how the actual data payload is encrypted. (Hint: They can't. Antivirus is exclusively "after the horse has bolted" security.
5) Really, Slashdot?
except that with big vendors like Nvidia, there is no memory protection (no good IOMMU support yet).
So they've demonstrated that ... you can store data in RAM.
Whoop-dee-fucking-doo.
Except that, due to the above, that *RAM* happens to be accessible to anyone who might give a try.
CPU:
Imagine you have a software in which you are editing your *super secret* document.
Imagine that there's a different software running in user space.
That software can't access your document - there's a MMU on the CPU enforcing memory protection. A piece of software can't reach out to a memory block it doesn't have explicit access granted.
GPU: ...but...
Now imagine that the editor displays your document on the screen. It goes through the compositor onto a buffer on the graphic card (either GPU RAM, or RAM accessed by the GPU), before finally getting assembled for displaying on the screen (that's a normal behaviour).
Now imagine you're also running a 3D game on the same computer. That game uses OpenCL to compute its physics.
one of the shader run on the GPU is actually a trojan: instead of reading from some buffer used for the physics computation, it reads using a pointer to the location of CPU RAM where the display buffer of the first program is.
It shouldn't be allowed to do so, but it does anyway. (e.g.: Nvidia's proprietary drivers) The request goes through and the game can siphon the output of the super secret editor. There's is (currently) nothing to enforce such memory protection and prevent one GPU shader to peek into buffers from another applications. Currently any shader running on the GPU can peek from any location it wants to.
Nvidia and AMD need to properly implement support for IOMMU & the MMU inside the GPU itself.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
No not at all. These are not dedicated devices, they're typically a stock processor, with an OS core that can load and update some software parts and those software parts do the function. In the case of the Sim card is a java machine used to provide services from the phone company to the phone.
If you call it firmware does it make it better?
These devices are programmable, have CPU and can be late programmed to change that firmware, in other words hacked to take over a computer.
GPU for example has DMA access to the main processor memory giving it free range over a lot of the system.
The update was how the NSA hacked the hard drivers, simply using the update facility to add their own software.
That was how they hacked Dell Server BIOSs, intercepting the BIOS update and sending their own updates instead.
For the modem they piggybacked their own software in the modem code.
For the sim card it was an update sent from network to the provided services.
How would you stop the NSA from fucking your life over?
By not having a life.
Have gnu, will travel.
The IOMMU solved this by even giving each IO device its own virtual IO memory space. So no, the GPU can't randomly read protected memory. Nvidia and AMD don't have to implement anything as this is the job of the IOMMU, not the endpoint device itself.
...except that their drivers don't use it. Yes, there's a IOMMU in modern CPU. No, current GPU drivers don't use it fully. (According to several source about this proof-of-concept neither Nvidia's nor AMD's drivers do properly use IOMMU to isolate de GPU. They basically just grant the device wholesale access to the memory).
Also, at least modern GPU form Nvidia have a MMU on the graphic card (doing the same job, but from the perspective of the GFX card: prevents 2 shaders from 2 different 3D applications from reading each-others data).
I've only read about this being used in GPGPU servers. I haven't heard about it being used in Nvidia OpenGL for games (maybe Nvidia has been just silent about that).
This was the same problem with the Firewire DMA exploit. Essentially before the IOMMU it was possible for any PCI card to randomly read any memory it wanted to.
Yes, and modern firewire drivers in linux correctly use iommus so only the necessary buffer is made available to the firewire controller.
But currently, that's not yet the case with GPU driver. Binary drivers by AMD and Nvidia, as reported in several articles about GPU malware, do not use iommus to specifically map only that sub-part of the memory that the GPU must have access to.
Though that could probably change in the future for AMD once their driver starts running above AMDGPU opensource kernel module. Somebody is bound to write proper support for that.
Also a IOMMU is only a shield between the RAM managed by the CPU and the access of a PCI-express card to it. (e.g.: between a firewire forensic device and the Linux PC).
A IOMMU doesn't have the slightest idea about what is happening outside, in the device it self.
(e.g.: it will protect the Linux machine from a rogue Firewire dongle plugged into a firewire hub. It won't prevent the rogue dongle from siphonning information directly from a harddisk plugged in the same hub, nor from another Windows machine plugged in the same hub. Firewire is multimaster / peer-2-peer, all trafic isn't necessarily routed through the Linux machine.)
Same with GPU :
- a IOMMU can prevent a GPU reading a pieces of RAM that it wasn't granted access to. (it won't steal your password by directly reading the data of the keyboard driver).
- a IOMMU doesn't have the slightest idea what is happening inside the card
- thus a shader sent for execution from a trojan, could have a broken pointer reading from the pixel buffer inside the video ram of another unrelated application. (it might be able to take screenshot, by peeking into the texture memory of the desktop compositor inside the VideoRAM).
That would require a MMU inside the GPU enforcing protection between the various pieces of shader code running on the GPU. modern GFX card do have them, but I've only read about them being used in the context of GPGPU servers.
- as far as I know (I'm not an OpenGL expert), the language used for graphics shader (GLSL) doesn't provide a facility to do so.
- but in my experience with GPGPU language (CUDA, and according to docs, the C subset provided by OpenCL) *do* have pointers (because that's how the hardware underneath works)
- so a badly written compute shader could end up reading a wrong memory location. (or a malicious 3d application could voluntary corrupt the cached pre-compiled graphics shader).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]