Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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.
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?
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.
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 , 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.
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?