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.
I think this is a solid idea and worth doing.
IT DOES rely on vendors making insecure devices.
Most (if not all) GPUs do not use an IOMMU.
Without an IOMMU to control the device, it can always scan the entire physical memory - and change things at any time. That is why USB devices can usually do the same thing. It is the SAME problem.
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
While it is true that antivirus stuff currently tends not to peek at GPU address space; given the frankly shit job that AV managed with its current access to RAM and HDD, the implied "let Norton GPU 2015 protect you!" Message seems like it might eat a lot of expensive memory bandwidth for very little reward. How about CPU vendors(especially looking at you, Intel) stop pretending that an IOMMU is some kind of fancy enterprise feature, rather than virtually essential to not being caught with your pants down when basically every peripheral on the PCIe bus is a remarkably capable little computer in its own right and allowed to DMA its merry way all over your address space.
Anyone know if you can possible prevent this from being exploited by turning off hardware acceleration in a browser? I think all browsers have GPU acceleration
turned on by default in most cases. I can't remember where I had read a couple years ago that someone had said with the advent of the GPU becoming more then just a graphics processor that the potential existed for it to be used for an attack.
Wow, a complete fud story on this.
nothing runs on the video card, they are string data there only.
Shashdot now taking stories from WIRED?
Do not look at laser with remaining good eye.
If the graphics cards aren't flushing RAM on reboot, how is that not a problem?
I really don't want mcafee or norton scanning my GPU's ram and "quarantining" the (false) positives.
Is a big joke... Those companies are rubbish..
They should have written their software to scan all writeable memory, audit all hardware firmware long long ago
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?
Thank you, for making my pc so slow, and now, you want to slow down my graphics performance also, and at the same time, increase power usage of my pc, and noise of my graphics cards... Thank you very much... I hope you will die a horrible long and painful death.... Oh and f**k you slashdot, for only allowing me to post from my ip and only 2 posts a day with account...
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 ]
Unless we go back to live in the cave, whatever we use has NSA's thumbprints all over
The one thing that this world truly needs is to have a device (or two) that can defeat NSA's implants throughout our homes --- not necessarily have to destroy the implants, if that device can generate enough disruptions to the embedded implants that'll be good enough
But then ... who are we kiddin'?
Even devices from Huawei --- supposed to be a branch of the Chinese red army --- came complete with NSA bugs
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.
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 ]
At the next supercomputing conference the GPGPU results are shown as-is, with ECC, and with anti-virus. Damn you Symantec for spilling all over my precious registers and texture cache!