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

A Berlin researcher has demonstrated the capability to detect previously undetectable stealthy malware that resides in graphics and network cards. Patrick Stewin's proof of concept demonstrated that a detector could be built to find the sophisticated malware that ran on dedicated devices and attacked direct memory access (DMA). The attacks launched by the malware dubbed DAGGER targeted host runtime memory using DMA provided to hardware devices. These attacks were not within scope of antimalware systems and therefore not detected. DAGGER, also developed by Stewin and Iurii Bystrov of the FGSect Technical University of Berlin research group, attacked 32bit and 64bit Windows and Linux systems and could bypass memory address randomisation.

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?

Originally Posted by H_TeXMeX_H Now that's something completely different for ya. I sure have never heard of such a possibility.

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...

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

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

Originally Posted by unSpawn 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)

Originally Posted by qlue So either the firmware or the firmware loader would need to be compromised first then, right?

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

Originally Posted by qlue wouldn't it be reasonable to run a malware check on firmware before it's loaded into the GPU?

How would you envision doing that?

Originally Posted by unSpawn Not if you can load it via a 3rd part DMA transfer?

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.

Originally Posted by unSpawn How would you envision doing that?

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.

Originally Posted by qlue Actually, DAGGER specifically uses first party DMA

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

Originally Posted by qlue The same way as any other virus scan works, by checking for signatures of known malware.

So how would GPU-backed encryption affect checking signatures?

Originally Posted by unSpawn Sure but the PoC currently still requires bootstrapping and a control process, right?

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)."

Originally Posted by unSpawn So how would GPU-backed encryption affect checking signatures?

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.

Originally Posted by qlue Apparently not.

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

Originally Posted by qlue This is irrelevant

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

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

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

Anti-virus software cannot detect malicious code stored in separate memory and executed on a different processor. (..) DAGGER operates stealthily. It is undetectable by anti-virus software etc.

Originally Posted by unSpawn Heh, why would the author of the document H_TeXMeX_H article links to say ""Anti-virus software cannot detect malicious code stored in separate memory and executed on a different processor. (..) DAGGER operates stealthily. It is undetectable by anti-virus software etc.""

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?