Malware that attacks DMA and hides in peripherals
 

This technically applies to all OSs, not just Linux:
http://www.scmagazine.com.au/News/35...ripherals.aspx
Now that's something completely different for ya. I sure have never heard of such a possibility.

I'm confused!?!?
Doesn't the firmware for peripherals get loaded at boot time? How would malware survive in there?

If you've read the related docs then you can only conclude OpenCL, CUDA and such are enablers and therefore this was something waiting to happen IMHO...


With the DAGGER PoC the code isn't stored in GPU flash ROM but loaded into the GPGPU on boot.

So either the firmware or the firmware loader would need to be compromised first then, right?
If that's the case, wouldn't it be reasonable to run a malware check on firmware before it's loaded into the GPU?
On the other hand, it seems that anyone who could replace the firmware with malware either has access to the target system or to the repos. In the former case, the administrator of the target system has serious problems anyway and in the latter case, the entire community has a major problem. (at least, whichever community is using that repo)

Not if you can load it via a 3rd part DMA transfer?


How would you envision doing that?

Actually, DAGGER specifically uses first party DMA to avoid alerting the CPU to the transfer and maintain stealth. Third party transfers use a DMA controller as the third party which, by design, alerts the CPU to the transfer.

Either way, however, you still have to get the malicious code loaded into the GPU before it can execute and effect any transfers.

The same way as any other virus scan works, by checking for signatures of known malware. Granted, this will not detected unknown malware.
Keep this in mind;
a.) only firmware files need be checked
b.) only signature of malware capable of 'stealthy' operation need be checked.




You can read the full paper by Patrick Stewin and Iurii Bystrov to get a better understanding of how this malware would operate.

Sure but the PoC currently still requires bootstrapping and a control process, right?


So how would GPU-backed encryption affect checking signatures?

Apparently not. From the paper I linked to;
"DMA Malware Fulfillment. We designed and implemented our DAGGER
prototypes according to the DMA malware definition described in Section 4.
(C1) is clearly fulfilled since it implements working keystroke logger functionality.
DAGGER needs no physical access for the infiltration process (C2). We infiltrate
the ME environment using a software based exploit during runtime. DAGGER
exploits dedicated hardware to implement rootkit properties (C3)."



This is irrelevant if the files are checked before they can be loaded as a signature must still exist.
However, after going through the paper a bit, I noted this;
"Checking firmware images at load time, as proposed by the
Trusted Computing Group [32], does not prevent runtime attacks."

So scanning the firmware files would not prevent all instances of such malware. Though it would still be pretty good start.

Well the 2102 version did ;-p And I think you missed the part where it says they had to subvert GRUB2?..


Never mind the fact that AV scanning on a CPU would be costly simply because of the massively parallel processing a GPU offers...


Heh, why would the author of the document H_TeXMeX_H article links to say

He is not talking about scanning files there, he is talking about the Anti-virus daemon processes that attempt to detect a virus that is already running. (storage vs ram)

You would not need, or even use, an anti-virus program during boot-up. I'm thinking more along the lines of a file integrity scanning routine as part of the booting process. We already run fsck on the hard drive, would a scan of firmware files be so much of an extra burden?