Malware Running On Graphics Cards

An anonymous reader writes "Given the great potential of general-purpose computing on graphics processors, it is only natural to expect that malware authors will attempt to tap the powerful features of modern GPUs to their benefit. In this paper, the authors demonstrate the feasibility of implementing a malware that can utilize the GPU (PDF) to evade virus scanning applications. Moreover, the authors discuss the potential of more sophisticated attacks, like accessing the screen pixels periodically to harvest private data displayed on the user screen, or to trick the the user by displaying false, benign-looking information when visiting rogue web sites (e.g., overwriting suspicious URLs with benign-looking ones in the browser's address bar)."

Comments

I guess it already happened to me

[Yvan256]

It says slashdot.org in my URL bar but since the last few months the comments of users appear to be from digg.

I am pleased

[Reilaos]

With this technology, new, more sophisticated Rickrolling is now possible.

Re:I am pleased

[jpapon]

cudaMemcpy(d_rickAstley,h_rickAstley, AMOUNT_OF_TIME*TO_GIVE_U_UP * sizeof(float) ,cudaMemcpyHostToDevice);

d_RickRolled >> (d_rickAstley);

I had an idea like this.

[RyuuzakiTetsuya]

except instead of doing that, it looked for textures that were generated anyway by games ads and swapped in other textures.

My friends looked at me like I was evil and crazy.

I will show them...

[halfEvilTech]

"Moreover, the authors discuss the potential of more sophisticated attacks, like accessing the screen pixels periodically and harvest private data displayed on the user screen"

I guess we just change all fields to mask the entries with **** or if we want to really fool them use dots.

Wrong summary

[blai]

Should read "nvidia adds twitter and pop3 integration to newest line of GPUs"

imagine

[KillaGouge]

Imagine starting to be target for specific porn habits. No amount of private browsing would keep the ads from showing up on your computer.

Re:imagine

[PPH]

Gotta log off now and start working on an algorithm to detect the presence of areola color and texture.

Hehe, what goes around comes around

[arivanov]

I used to run a small computer repair and write-to-order software shop for a living while in the Uni with two more people. One of them had that idea around 1994. In those days it was just to store the code in the video RAM pages which are not directly accessible to a scanner and keep a small polymorphic backstrap routine in main memory.

What goes around comes around. Looks like this is using a similar approach. Even if you compute some stuff on the card you still need a bootstrap within the main system to use it and talk back to the "mothership".

Re:Hehe, what goes around comes around

[postbigbang]

Now that I think of it, my electric razor with new programming, was trying to attack me this morning, or so it seemed...

Re:Hehe, what goes around comes around

[Rich0]

I agree that somehow the code has to get into the GPU, which means a bootstrap of some kind from the main CPU. I'm not sure it has to remain in the main memory for any period of time, however, as long as the graphics card has DMA access back into main memory.

I'm not sure how memory protection works on the most modern systems, but at least in the past DMA had wide-open access to everything. So, if the graphics card needed to get back into the CPU for a short time, it could just modify the interrupt descriptor table, trigger an IRQ, and so on. Or, it could patch any code in RAM to run, and then replace it back when it was done. Then again, I'm not sure if it is strictly necessary to ever get back into RAM - perhaps the virus could just directly talk to the NIC/HD/etc and get whatever it needs done. Who needs the main CPU?

Again, I'm not familiar enough with PCI/etc to know if this is practical. But I bet you could exploit a lot of code that is already in the system.

Re:Hehe, what goes around comes around

[TheRaven64]

DMA is not a problem. It goes via the GART (and has since the AGP days), so the GPU can only see the bits of memory that it is explicitly shown. A bigger problem is that separate processes may not be isolated from each other on the GPU, so your WebGL program and your window server may be running in the same virtual address space on the GPU. Your WebGL program is then free to read or write any window's contents, as long as it can find the correct virtual address for the buffers.

Re:Hehe, what goes around comes around

[faragon]

A big problem in 1994 was the poor quality of DRAM used in graphics cards and/or tight DRAM timmings (many SVGA cards had overclocked DRAM, specially the ones running in VESA Local Bus 32-bit bus for i80486 CPUs).

Popups 2.0

[BradleyUffner]

This should make for some wonderful new kinds of pop up ads that can't be dismissed or in any way taken out of focus.

Process Authentication and Authorization

[Doc Ruby]

User and role based authentication/authorization is essential to security, but not sufficient. A machine that brings authentication/authorization down to the process level would be more secure.

I'd like a PC that enforced access control on each process running. Every call to any HW, whether CPU, MMU, GPU, or any bus, to require authentication. A crypto ASIC with scores of simultaneous auth units pointing at each process space and the ACL table for auth in just a few extra clock ticks on operations per process, at startup and randomly every dozen or so calls. More frequently when there's a "heightened alert" either by network notification or during and after other security events like DoS attacks and malware discovery.

Re:Process Authentication and Authorization

[Anonymous Coward]

I, too, want my system to crawl to a halt due to a bunch of authentication overhead.

Re:KISS

[jpapon]

Eh, this is way sneakier, and could be far more effective, since you could modify/hide anything from the user.

It would be pretty difficult to determine which pixels are the URL bar on the GPU though. Unless of course all this GPU acceleration they're putting in browsers now allows you to somehow read the coordinates directly.

Re:KISS

[nospam007]

Sure it would. It changes pixels directly onscreen, the browser/app/whatever will never know.

Driver problem

[TheRaven64]

Modern GPUs include memory protection, so different processes can be prevented from reading each others' VRAM, just as they can be prevented from running each others' RAM. This is not always used by the drivers, which may just map the entire physical VRAM into the GPU's virtual address space. With properly written drivers, this is much harder.

The big malware potential comes from WebGL. This allows you to run arbitrary GLSL code in the browser's (GPU) address space. Although you probably can't take over the entire display, you can potentially take over the entire browser window without permission. Hopefully, the driver will give you entirely separate GPU address spaces per GL context, but given how incompetent AMD and nVidia's driver teams have demonstrated themselves to be, I doubt it.

Sigh

[Dancindan84]

Headline: "Malware Running On Graphics Cards"
TFS/TFA: "Here's a paper showing that malware on graphics cards is theoretically possible and could possibly evade detection."

If you were trying to sensationalize the headline, you might as well have thrown "won't anyone think of the children!?!?" in there as well.

Re:KISS

[jpapon]

Maybe, but people have so many addons and toolbars it would be a pretty rough guess.

Re:KISS

[wealthychef]

If you know the coordinates of the window, then you can make a pretty good guess as to the location of the URL bar.

Not in my browser. When you add extensions, the URL field moves to accomodate them. I would guess similar behavior is common elsewhere. I think this attack is going to be hard to do in practice.

Re:KISS

[TheRaven64]

It would be pretty difficult to determine which pixels are the URL bar on the GPU though.

No, not really. The browser window's address bar is a pretty easy shape for simple computer vision algorithms to spot, and you've go access to a nice parallel processor to run them on...

Re:Government researchers?

[blair1q]

Before you can build a wall, you have to imagine someone walking over the imaginary line at the edge of your yard.

Or you can figure out that a wall would have been useful after they come into your yard, but then it's too late.

See, most taxpayers understand that we pay taxes to prevent the crime, we don't wait until it happens and then rail that the government isn't doing anything about it.

Re:Is this possible in a correctly configured Linu

[TheRaven64]

No, you're thinking at the wrong level. The problem is that every application that gets an OpenGL context can upload programs to the GPU and run them. Fine in theory, and a modern GPU has the ability to isolate different context's memory from each other, but the drivers don't always use it (and don't always use it correctly when they do). If you're using an nVidia or ATi blob driver, then you have the same code controlling the GPU as a Windows user, so if the vulnerability is on Windows it will also be on Linux.

The latest versions of Nouveau do provide some support for giving different contexts different virtual address spaces, but this support may not always be used correctly. I've no idea about ATi / AMD drivers.

If you don't have on-GPU memory protection properly configured, then any GLSL, OpenCL, CUDA, HLSL, or whatever, program can access any of the GPU's memory. This means that anything in VRAM, including the contents of every on-screen window (and even some off-screen ones if you're on a system like OS X, X11 with a compositing manager, or Windows with Aero) is available to the malware.

Re:KISS

[nschubach]

Unless you run IE/Win Vista/7, where the address bar cannot be moved or removed (I've tried) and is a calculable distance from the top and left.

Although it's not the original reason I wish I could move the elements of that top bar, I just might have to add it to my list.

(XP lets you move the address bar practically anywhere, so it would be harder to "guess" unless you were to read API messages concerning the stored location of said bar.)

Re:Malware everywhere

[Mister Whirly]

There is malware that runs on network printers already. There was the Hoots worm that printed out the picture of an owl with "O RLY" on it.

Re:KISS

[jpapon]

Yeah, I suppose. I could make this happen today if I knew how to dump the screen buffer contents to a readable array in device global memory in CUDA.

Re:KISS

[h4rr4r]

All the malware has to do is add a CA it already owns.

Re:KISS

[sjames]

Fortunately, it's running on the GPU, which we all know from the marketing hype is an amazing infinitely powerful CPU. It will have no problem running a recognition program to find the URL bar.

Threats are not serious

[dmitriy]

None of the described future attacks are feasible. Shared framebuffer is not accessible to applications directly for security reasons (authors think that this is "unfortunate"); direct access to framebuffer is not "inevitable" in the future -- much better technique is to use driver-controlled fast GPU blits: data doesn't leave GPU. Non-timesharing is non-issue -- driver can detect timeouts and reset hardware (TDR on Vista).

So the only issue is polymorphic virus that may use GPGPU decryption. If this happens, scanners will start using CUDA, or GPU virtualization.