Intel says GPU malware is no reason to panic, yet

Intel's new power-efficient graphics core
Intel's new power-efficient graphics core Credit: Intel

Running malicious code inside GPUs leaves detectable traces on computers, researchers concluded.


Malware that runs inside GPUs (graphics processing units) can be harder to detect, but is not completely invisible to security products.

Researchers from Intel division McAfee Labs teamed up with members of Intel's Visual and Parallel Computing Group to analyze a proof-of-concept GPU malware program dubbed JellyFish that was released in March.

Their conclusion, which was included in McAfee's latest quarterly threat report, is that running malicious code inside GPUs still has significant drawbacks and is not nearly as stealthy as its developers suggested.

JellyFish's creators claimed that one of the advantages of GPU malware is that it can snoop on the host computer's memory through a feature called DMA (direct memory access).

While this is true, exposing critical portions of the system's memory to the GPU requires kernel privileges and must be done through a process that runs on the host computer.

Security products can monitor for and restrict such operations, the Intel researchers said. Furthermore, "this dependency is subject to existing kernel protections."

If the installation of the GPU malware is achieved without detection, the user code and kernel driver used in the process can theoretically be deleted from the host operating system. However, this might cause problems.

For example, on Windows, orphaned GPU code triggers a Timeout Detection and Recovery (TDR) process that resets the graphics card, the McAfee researchers said. The default timeout before this mechanism kicks in is two seconds and any attempt to alter that value can be treated as suspicious behavior by security products, they said.

In addition, long-running GPU processes will lead to the OS graphical user interface becoming non-responsive, which can betray the presence of malware.

Therefore, the best option for attackers would be to keep a process running on the host computer, the researchers said. This code can be minimal and harder to detect than a full-blown malware program, but is nevertheless something that security products can identify.

Another claim made by the JellyFish developers was that code stored on the GPU persists across system reboots. This refers to data storage rather than code that automatically executes, according to the Intel researchers.

"The idea of persistence claimed here is that a host application is running at system startup, retrieving data from GPU memory, and mapping it back to userspace, which is not nearly as daunting because malicious usermode code must also persist outside of the GPU," they said.

While it's true that there is a shortage of tools to analyze code running inside GPUs from a malware forensics perspective, endpoint security products don't need such capabilities because they can detect the other indicators left by such attacks on the system.

On one hand, moving malicious code inside the GPU and removing it from the host system makes it harder for security products to detect attacks. But on the other, the detection surface is not completely eliminated and there are trace elements of malicious activity that can be identified, the researchers said.

Some of the defenses built by Microsoft against kernel-level rootkits, such as Patch Guard, driver signing enforcement, Early Launch Anti-Malware (ELAM) and Secure Boot, can also help prevent the installation of GPU threats. Microsoft’s Device Guard feature in Windows 10, which allows only Microsoft-signed and trusted applications to run, can be particularly effective against such attacks, according to the researchers.

While both attackers and defenders will likely continue to refine their moves on the GPU battleground, the researchers said that the recent focus on this area has made the security community consider improving its approach to these threats.

Must read: Hidden Cause of Slow Internet and how to fix it
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies