Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Malware Running On Graphics Cards

CmdrTaco posted about 4 years ago | from the freeing-up-the-cpu dept.

Security 103

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

Sorry! There are no comments related to the filter you selected.

I guess it already happened to me (5, Funny)

Yvan256 (722131) | about 4 years ago | (#33712860)

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

That's because Vlad Farted (-1, Troll)

Anonymous Coward | about 4 years ago | (#33712960)

Re:I guess it already happened to me (0)

Anonymous Coward | about 4 years ago | (#33715776)

I have that one too.
Sometimes, in the later hours, the comments might even be from 4chan.

I am pleased (5, Funny)

Reilaos (1544173) | about 4 years ago | (#33712864)

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

Re:I am pleased (3, Funny)

jpapon (1877296) | about 4 years ago | (#33713226)

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

d_RickRolled >> (d_rickAstley);

Re:I am pleased (1)

PseudonymousBraveguy (1857734) | about 4 years ago | (#33713674)

Rewriting arbitrary stuff on your screen is possible for any virus without "infesting" the GPU. You own the OS, so you can force the GPU to paint anything you want without running specialized code on it. Actually, simply changing the contents of your screen was all what most old DOS-virii did. The interesting part is the "hiding from detection" part, not the "yet another way to write stuff on the screen" part.

Re:I am pleased (1)

neumayr (819083) | about 4 years ago | (#33714408)

That so? I thought owning a modern OS wouldn't give you the hardware access you had in the ol' days of DOS, not by a long shot. Just freely drawing around the screen doesn't work. Getting your code run by the GPU OTOH..
Maybe I should actually read what this story is about, seems interesting.

Re:I am pleased (1)

somersault (912633) | about 4 years ago | (#33720766)

That so? I thought owning a modern OS wouldn't give you the hardware access you had in the ol' days of DOS, not by a long shot. Just freely drawing around the screen doesn't work.

Yeah I hate these modern OSes where all the apps, games, screensavers, desktop buddies etc can't just freely output to the screen.. it makes Photoshop and CAD really difficult to use :s

Re:I am pleased (0)

Anonymous Coward | about 4 years ago | (#33714458)

oh no, I've been slashrolled.

Re:I am pleased (1, Flamebait)

hairyfeet (841228) | about 4 years ago | (#33715464)

Ooooohhh no, you're not thinking evil enough. If you are gonna go to THIS much trouble, you need to go WMD evil, like this:cue twilight zone theme imagine if you will, a poor PC user, slowly being driven out of his mind, because no matter what he clicks, no matter where he goes, all he gets is "The Safety Dance" on an endless loop while a midget moons him onscreen. He tries to play a game? Safety Dance. Watch a video/listen to music? Safety Dance. no matter how many times he reboots he cannot escape the asshole zone

As for TFA, seriously though how easy would such an attack be? It isn't like CPUs where you only have AMD and Intel, with GPUs you got a million of those from the old DX7s to the latest multi core monsters, you got chips by ATI, Nvidia, Intel, Via, SiS, so wouldn't that raise the PITA factor by like a thousand? even if you targeted the lowest common denominator, like say DX8, aren't there differences between the way ATI, Nvidia, and Intel do things? And looking at TFA they are targeting CUDA, and don't you have to have support for that installed? Which would make the target so teeny tiny that unless you were really pissed at Pixar or something would make this not worth the trouble? And if written in CUDA it won't work on ATI, yes? I guess one more reason to be happy I switched to an AMD/ATI only shop.

Maybe I'm just too old a greybeard and am not getting it, but I always thought the point of malware was to hit as big a target as possible. Wouldn't this make the target so tiny as to not be worth the effort? Why would a malware writer go for this over say the latest Adobe Reader/Flash hole?

Re:I am pleased (1)

hairyfeet (841228) | about 4 years ago | (#33718302)

Hey moron mod? How exactly is responding to someone who wants to use the GPU for a Rickroll with a suggestion of using safety dance in its stead flamebait? what are you, a midget bigot or just someone with a hard-on for the 80s? If I had wanted to go flamebait I would have suggested the RMS eats toe cheese [youtube.com] or maybe Linus giving a thumbs up to win 7, dumbass.

And nobody answered my question, will CUDA code work on ANY modern GPU, or just Nvidia? does one need to have CUDA installed for it to work? will it work on the older DX9 GPUs that are still in heavy use in laptops, like the Intel chips? Because unless the correct answers are yes, no, yes ,yes, then the target would be so small as to make it trivial to protect against. After all how many average folks have an Nvidia modern GPU PLUS have Cuda installed PLUS no sandboxing? Because if one is skilled enough to have the CUDA framework installed most likely they ain't using IE, but more likely a sandboxed browser like Chrome or have a sandboxing AV like Comodo. This seems like one of those things where you're more likely to win the lotto than pull this off, ala the Linux local privilege escalation exploits.

Re:I am pleased (1)

somersault (912633) | about 4 years ago | (#33720786)

I am not a CUDA developer, but I'm pretty sure that yes it only works on nVidia GPUs, but no you don't need to install the CUDA SDK to be able to run CUDA apps, all you need is the hardware. So it would be a pretty big target really.

I know that malware authors would think of doing this eventually, but I still think that giving them ideas like this is Bad. Just look at what happened with Twitter this week - someone releases a harmless proof of concept type attack, and now already the script kiddies are coming out with more malicious versions. Not that I even care as I don't use Twitter, but it's a good example of how these guys are often too dumb to invent new types of attack without help.

KISS (0)

Anonymous Coward | about 4 years ago | (#33712914)

trick the users 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).

I suppose editing the hosts file to redirect traffic wouldn't suffice?

Re:KISS (1)

marcansoft (727665) | about 4 years ago | (#33713014)

Nope, it wouldn't suffice for SSL sites.

Re:KISS (2, Interesting)

nospam007 (722110) | about 4 years ago | (#33713334)

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

Re:KISS (1)

tepples (727027) | about 4 years ago | (#33713636)

It might suffice for SSL sites if one of the CAs is authorizing the malware. With several governments acting as CAs, this is likely to become a possibility very soon.

Re:KISS (3, Insightful)

h4rr4r (612664) | about 4 years ago | (#33714208)

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

Re:KISS (3, Insightful)

jpapon (1877296) | about 4 years ago | (#33713296)

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 (1)

M. Baranczak (726671) | about 4 years ago | (#33713408)

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

Re:KISS (3, Insightful)

jpapon (1877296) | about 4 years ago | (#33713700)

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

Re:KISS (3, Interesting)

sjames (1099) | about 4 years ago | (#33714324)

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.

Re:KISS (2, Interesting)

wealthychef (584778) | about 4 years ago | (#33713704)

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 (2, Interesting)

nschubach (922175) | about 4 years ago | (#33713988)

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:KISS (1)

psbrogna (611644) | about 4 years ago | (#33714910)

Breaking key-based encryption used to be considered hard to do. Bring more horsepower to bear, ie. a GPU, and today's Hard To Do turns into a Proof of Concept and eventually becomes tomorrow's Commonplace.

Re:KISS (1)

somersault (912633) | about 4 years ago | (#33720848)

Sorry, but if you think adding a few GPUs into the mix is going to make a difference, you don't have much idea about cracking encryption.

Unless you figure out a weakness in the algorithm, you are not brute forcing a 128 bit key without either a lot of luck, centuries of time, or a quantum computer.

Here's a quote from an article about encryption [zdnet.com] .

Ah, but what about the dreaded massively distributed cracking brute force method for attacking something like 128 bit RC5 encryption? There are massive zombie farms of infected computers throughout the world and some may have gotten as big as 1 million infected computers. What if that entire army was unleashed upon the commonly used 128 bit RC5 encryption? Surprisingly, the answer is not much. For the sake of argument, let’s say we unleash 4.3 billion computers for the purpose of distributed cracking. This means that it would be 4.3 billion or 2 to the 32 times faster than a single computer. This means we could simply take 2 to the 128 combinations for 128-bit encryption and divide it by 2 to the 32 which means that 2 to the 96 bits are left. With 96 bits left, it’s still 4.3 billion times stronger than 64 bit encryption. 64 bit encryption happens to be the world record for the biggest RC5 bit key cracked in 2002 which took nearly 5 years to achieve for a massive distributed attack.

Now that we know that the distributed attacks will only shave off a few bits, what about Moore’s law which historically meant that computers roughly doubled in speed every 18 months? That means in 48 years we can shave another 32 bits off the encryption armor which means 5 trillion future computers might get lucky in 5 years to find the key for RC5 128-bit encryption. But with 256-bit AES encryption, that moves the date out another 192 years before computers are predicted to be fast enough to even attempt a massively distributed attack. To give you an idea how big 256 bits is, it’s roughly equal to the number of atoms in the universe!

Re:KISS (3, Interesting)

TheRaven64 (641858) | about 4 years ago | (#33713840)

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:KISS (3, Interesting)

jpapon (1877296) | about 4 years ago | (#33714006)

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 (1)

listentoreason (1726940) | about 4 years ago | (#33718910)

Thid is whu I usw a dynakicly genwrated captcja fomt. Supdr-secire, witr onky minor typo skde effrcts.

I had an idea like this. (2, Interesting)

RyuuzakiTetsuya (195424) | about 4 years ago | (#33712988)

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... (5, Interesting)

halfEvilTech (1171369) | about 4 years ago | (#33713000)

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

Re:I will show them... (1)

noidentity (188756) | about 4 years ago | (#33713558)

Yes, because I always display all private data as a bunch of asterisks. Passwords aren't the only private thing.

Re:I will show them... (1)

jpapon (1877296) | about 4 years ago | (#33713774)

I actually made a plugin once that did exactly that... it made all the text onscreen asterisks (or just random garbled text), and only showed you the actual text when you highlighted it.

Of course, I could never find a use for it besides installing it on friends' computers when they weren't looking...

Re:I will show them... (1)

lowrydr310 (830514) | about 4 years ago | (#33714362)

Would you mind sharing the code?

I'm trying to create a similar plugin, only converting a specific type of text to garbage; the problem is that I don't have time to start from scratch and I can't find anything similar to start with as a base.

Re:I will show them... (1)

jpapon (1877296) | about 4 years ago | (#33714600)

Let me look around... This was back in Uni, but I may have it on one of my old archive externals at home.

Re:I will show them... (0)

Anonymous Coward | about 4 years ago | (#33713966)

Or you can rip out the graphics card completely and operate the machine through a remote terminal on the serial port...

Re:I will show them... (1)

hedwards (940851) | about 4 years ago | (#33714070)

Malware writers have been doing something like that for a while now. Mainly to deal with screen keyboards that some lending institutions require. I'm not sure that it's particularly prevalent at this point, but the technology is already there to exploit that.

Re:I will show them... (1)

JohnnyBGod (1088549) | about 4 years ago | (#33714392)

You're really uncreative. What about those on-screen keyboards banking sites use? Just access the display data, combine with a click logger and presto! You now have access to a person's banking.

Wrong summary (3, Funny)

blai (1380673) | about 4 years ago | (#33713020)

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

imagine (3, Insightful)

KillaGouge (973562) | about 4 years ago | (#33713048)

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 (2, Funny)

PPH (736903) | about 4 years ago | (#33713846)

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

Re:imagine (0)

Anonymous Coward | about 4 years ago | (#33715424)

Or zucchini

Hehe, what goes around comes around (4, Interesting)

arivanov (12034) | about 4 years ago | (#33713050)

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 (3, Funny)

postbigbang (761081) | about 4 years ago | (#33713518)

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 (2, Interesting)

Rich0 (548339) | about 4 years ago | (#33713754)

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 (3, Informative)

TheRaven64 (641858) | about 4 years ago | (#33713878)

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 (1)

Junior J. Junior III (192702) | about 4 years ago | (#33715358)

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.

So which one of you guys is the guilty party?

Re:Hehe, what goes around comes around (2, Informative)

faragon (789704) | about 4 years ago | (#33715444)

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 (4, Interesting)

BradleyUffner (103496) | about 4 years ago | (#33713056)

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.

Re:Popups 2.0 (1)

hedwards (940851) | about 4 years ago | (#33714108)

Indeed, this would be one step harder to deal with than those stupid javascript prompts which can't be canceled without popping up again or killing the entire browser.

Re:Popups 2.0 (1)

Monkeedude1212 (1560403) | about 4 years ago | (#33714380)

Well thats already an issue - I've seen Malware that makes fake "Blue Screen of Death" with the warning about viruses. You can't Alt+tab or Alt+f4 out of it, CTRL+ALT+Delete does nothing, it acts just like a Blue Screen of Death except for 2 things: Your mouse is still visible and moves, and it'll actually go away if you leave it for 5 minutes - instead of everyones initial reaction to reboot the machine.

I always wondered how it was they managed to bypass all the other functions that I should have had available, but THIS makes sense. I wouldn't be surprised if this kind of malware already exists.

Re:Popups 2.0 (1)

Mashiki (184564) | about 4 years ago | (#33717094)

By using rootkits and system level injections. That's the only way to do it, and Vundo(and varients) is probably the most famous offender of it.

Process Authentication and Authorization (3, Interesting)

Doc Ruby (173196) | about 4 years ago | (#33713112)

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 (2, Funny)

Anonymous Coward | about 4 years ago | (#33713200)

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

Re:Process Authentication and Authorization (1)

Doc Ruby (173196) | about 4 years ago | (#33713348)

Then don't get the auth ASIC I helpfully described, or use it infrequently the way I helpfully described.

Re:Process Authentication and Authorization (0)

Anonymous Coward | about 4 years ago | (#33713648)

It was called Vista.

Re:Process Authentication and Authorization (1)

Movi (1005625) | about 4 years ago | (#33714010)

This is more or less how the new game consoles (X360 and PS3) work.

Re:Process Authentication and Authorization (1)

BitZtream (692029) | about 4 years ago | (#33714028)

So I'm guessing you've never used any modern security focused operating system.

We've had everything you've mentioned for years ... probably 30 years or more.

The problem is, if you want to get anything done in a reasonable amount of time, you're going to turn all that stuff off. When you hook EVERY syscall things tend to get mighty slow. Go run some software in a profiler and you'll get a rough idea of just how shitty it performs in the real world.

Theres a reason general purpose operating systems don't do it, they want to accomplish more and can sacrifice security to do so. In other cases, security is more important than performance and so you end up with Trusted[BSD|Solaris|AIX|ect] where you can control things on a much more granular level.

Re:Process Authentication and Authorization (1)

Doc Ruby (173196) | about 4 years ago | (#33714690)

I have. All of which is why I want the machine to have an ASIC that effectively adds an AUTH instruction that takes only a few clock cycles, rather than do this essential operation in software every time, also caching credentials and grants in ASIC RAM or LUT.

Re:Process Authentication and Authorization (0)

Anonymous Coward | about 4 years ago | (#33715508)

What good would this do? It only works when you have very fine-grained ACLs, and nobody wants to sit there specifying exactly which of their processes should have access to exactly which of their files. Furthermore, it's pointless because sending emails (spam) doesn't even involve accessing files, or even the SMTP port. I'd love to see your hardware design for a system that would prevent rogue websites from using JS to send spam tweets or Gmail messages on my behalf!

dom

Re:Process Authentication and Authorization (1)

Doc Ruby (173196) | about 4 years ago | (#33715556)

I think it would work very well to support rules like "no browser process can access my disk" plus "email processes can access my disk", even if email is running as my user and so are other processes. Think of host firewalls like ZoneAlarm that assign permissions for network access per process per user, but applied to the entire range of HW.

Re:Process Authentication and Authorization (1)

fatphil (181876) | about 4 years ago | (#33720906)

"no browser process can access my disk"

You want no caching at all?
You want 'save page source' to not be possible?
You want it impossible to download anything off the web?
You want it to be impossible for external document viewers to view temporary files?
You want there to be no persistent cookie storage?
You want there to be no persistent storage of any settings that could be changed from within the program?
You want there to be no possibility for plugins?

Your hypothesised browser would apparently have a user-base of at most 1 with that feature-set.

Re:Process Authentication and Authorization (1)

Doc Ruby (173196) | about 4 years ago | (#33721630)

Sometimes, yeah.

Really, though, you're too dense to understand that such a use case is an arbitrary one that isn't the entire feature. Which is why I mentioned ZoneAlarm for an example. How about "no processes but the ones I've allowed today (before I connected the network) can access my disk or my network, until a dialog box adding them to the ACL is approved"?

Snow Crash anyone?! (1)

awilden (110846) | about 4 years ago | (#33713214)

So when can we expect the GPU port of the nam-shub to protect us from the Cult of A5h3rah?

Re:Snow Crash anyone?! (1)

arkane1234 (457605) | about 4 years ago | (#33717080)

The moment another shitty story writer pops up.

Security funny - linking PDFs on Malware... (0)

Anonymous Coward | about 4 years ago | (#33713290)

Linking to a PDF...on Malware...on Slashdot...

Rrrrriiiiight. Thank god for Google Docs, for us poor schmedricks that are corporately damned to use Adobe Acrobat, at least there's SOME way to view PDFs without risking the local system. Dear editors, please consider pointing to cached html copies or other locales first.

Re:Security funny - linking PDFs on Malware... (0)

Anonymous Coward | about 4 years ago | (#33717738)

Google Docs is slow and ugly.

Malware everywhere (1, Interesting)

Anonymous Coward | about 4 years ago | (#33713306)

I have seen somewhere botnets on routers here in slashdot.

What's the next device to be infected? Network printers? SSDs with that little ARM to perform GC? NICs?

Re:Malware everywhere (2, Interesting)

Mister Whirly (964219) | about 4 years ago | (#33714000)

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.

Driver problem (4, Interesting)

TheRaven64 (641858) | about 4 years ago | (#33713356)

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.

Re:Driver problem (1)

Subliminalbits (998434) | about 4 years ago | (#33714024)

That sounds nice in theory, but I know that at least with NVIDIA's computing driver there isn't a whole lot of memory protection going on. My experience has been that its not terribly difficult to crash your entire system with a user level program.

hopes for Gallium3D (1)

DrYak (748999) | about 4 years ago | (#33721310)

then this gives us hopes for the Gallium 3D driver stack to fix this and implement proper memory protection on hardware supporting it. Well, to bad for Windows users.

and nonetheless, AdBlock+ and NoScript will very probably block GLSL as they does with any other scripting language. So shoddy websites won't be able to assault you with unstopable full window ads. Well, to bad for IE users.

Is this possible in a correctly configured Linux? (0, Offtopic)

erroneus (253617) | about 4 years ago | (#33713454)

I don't want to plow the horn or wave the flag unless I know it's true. But given the various access levels and things that Linux uses in X.org and all that, I wonder if those same issues are more or less likely in a Linux + X situation?

To my understanding, there is not direct reading or writing to the screen. There is screen capture functionality, but I don't know how it works or if it is simply a standard feature of the X window system (and either way, is THAT a vulnerability to be wary of?).

In Windows land, with so many programs requiring "Administrator" level access (yes, I know, that situation is not nearly as bad as it once was, but still) this sort of malware attack vector seems as natural as any others. But does Windows security even consider this sort of breach? I imagine some aspects of device drivers are protected, but does it require privilege escalation to execute one of these attacks? I do recall that recently I was trying to use a PDF password cracker that enabled advanced CPU *and* GPU instructions to perform the processor work of trying to brute force attack a PDF open. I was not running as Administrator at the time but I don't recall that my user account has administrative privileges by default. (I don't believe it does though)

Theo warned about this years ago (0)

Anonymous Coward | about 4 years ago | (#33713626)

Only if the X server or another root process is compromised, I think. Reminds me of this warning from Theo years ago:
http://marc.info/?l=openbsd-misc&m=114738577123893&w=2 [marc.info]

Re:Theo warned about this years ago (1)

erroneus (253617) | about 4 years ago | (#33713862)

Oh boy... After reading through the first four paragraphs, I was reminded of Direct/Active-X. Device drivers in userland? I kinda knew about this but I guess I wanted to push it from my mind.

Is it really possible to have an advanced graphics environment with all the performance we desire without the windowing system having direct access to hardware? I suppose it would only be possible with an extremely rich API and high-speed communications interface and a whole lot of other things which would otherwise create a slow and complex means of interaction.

I guess from a security standpoint, all anyone who is Pro-Microsoft has to do is link to that page to prove that Desktop Linux isn't a whole lot better than Windows.

(But then again, none of my servers run X at all.)

root-less X still problematic (1)

Sits (117492) | about 4 years ago | (#33714200)

With kernel modesetting, it is possible to run an accelerated X without root privileges (MeeGo does this) but currently there are safety caveats [lwn.net] . To support multiple simultaneous users there is a need for a revoke syscall otherwise other users could snoop your input devices by not dropping previous access to devices (you can watch some X devs discussing the issue on Phoronix [phoronix.com] ).

Re:Is this possible in a correctly configured Linu (2, Informative)

TheRaven64 (641858) | about 4 years ago | (#33713940)

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.

Sigh (2, Insightful)

Dancindan84 (1056246) | about 4 years ago | (#33713486)

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:Sigh (1)

DIplomatic (1759914) | about 4 years ago | (#33713650)

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.

No kidding! This is just as bad as as that rail-gun rocket launcher headline from 2 weeks ago that had nothing to with crazy weapons.

I see what's going on (1)

microbee (682094) | about 4 years ago | (#33713644)

"I was really not watching porn, it was just the virus that infected my geforce!"

Government researchers? (1, Interesting)

Chemisor (97276) | about 4 years ago | (#33713654)

Does anyone find it disturbing that taxpayers' money is used to do the bad guys' work for them? I can understand researching anti-malware strategies, but why are these people given money to come up with bad things to do to my computer?

Re:Government researchers? (4, Insightful)

blair1q (305137) | about 4 years ago | (#33713898)

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:Government researchers? (1)

hedwards (940851) | about 4 years ago | (#33714178)

Except for the loud mouths that seem to think that the only acceptable solution to crime is more jails and longer sentences.

For the most part if you wait until you're attacked to deal with it, you've already lost and you're pretty much stuck with damage mitigation at best.

Re:Government researchers? (1)

fmoliveira (979051) | about 4 years ago | (#33716274)

Better than judges being forced to release criminals because we were out of jails, as happens frequently in Brazil.

Re:Government researchers? (1)

blair1q (305137) | about 4 years ago | (#33717082)

Most people get the point after being arrested. Others after being jailed for a few days.

It's when when you're releasing violent, repeat, or crazy offenders for budgetary reasons you know your legislature is missing the point.

Re:Government researchers? (1)

Hatta (162192) | about 4 years ago | (#33714188)

No, not in the least. You have to know where you are vulnerable to know what to protect. This is much like medical research, you have to know how to induce a disease in order to test new treatments.

Re:Government researchers? (0)

Anonymous Coward | about 4 years ago | (#33714224)

Uhm, because now a counterstrategy can be implemented as opposed to, say, when your computer is already infected? I'm pretty sure that the bad guys also have a brain or two and can figure this out for themselves.

Re:Government researchers? (1)

martas (1439879) | about 4 years ago | (#33715636)

no, because security through obscurity can only go so far. and not having realized that this entire new class of exploits are possible is obscurity.

Does have the gpu in the cpu make it easy to (1)

Joe The Dragon (967727) | about 4 years ago | (#33714608)

Does have the gpu in the cpu make it easy to get on the system / make it harder to get rid of?

Imagine the rootkits... (1)

Almahtar (991773) | about 4 years ago | (#33715278)

If you were able to use the GPU to brute-force a password hash or similar authentication token for the system, you could install a rootkit on the card's option ROM.

1.It'd get to run with ring 0 access on each boot before the OS has a chance to do anything.
2. On EFI systems it'd have access to a TCP stack, full FAT and NTFS filesystem access, all included in the EDK [transact.net.au] . So it could update itself on the fly each boot.

The video card makes a great trojan horse to house your malware.

IE9 Question (1)

pkinetics (549289) | about 4 years ago | (#33716034)

So does this mean that IE9 with its GPU acceleration can be used as the avenue for attack?

I fail to see how this is a big deal (1)

Sycraft-fu (314770) | about 4 years ago | (#33716664)

Once a virus is running on a system, it can shut down virus scanners, and all that kind of stuff. That is always the case. Doesn't matter where it runs. The key is to keep it from running and that's what virus scanners do. They are the doormen, they stop people who are on the "Bad list" from coming in. Well even if your virus was GPU based, it'd still have to come in and execute on the CPU like normal. There is no way to directly load something in the GPU and run it there. As such the virus scanner would get to have a sniff at it and determine if it got to run.

Also, GPU code still has to have a CPU component. The system doesn't have tasks that run just in the GPU. They even note this in their paper. Their "proof of concept" solution? Oh the malware will be "packed" in the CPU code and then unpacked to the GPU. Oh, executable packing/encryption. Ya viruses haven't done that since always. Sorry guys, but virus scanners are wise to that. They check for packed code.

So really, I don't see anything special here. It is the same situation as now where you run the virus scanner to keep the baddies out. If a computer is already infected, it can keep the AV software out and you need to scan it offline.

Plus this kind of malware might be easier to deal with: Just shut down GPU processing. Unlike the CPU, that is a feasible thing to do. So if a system is infected, the GPU gets turned off, the malware cleaned, the GPU restarted. Graphics cards still work fine when addressed in old "Just a bunch of pixels," mode.

Re:I fail to see how this is a big deal (1)

c0lo (1497653) | about 4 years ago | (#33717338)

Oh, executable packing/encryption. Ya viruses haven't done that since always. Sorry guys, but virus scanners are wise to that. They check for packed code.

So really, I don't see anything special here.

What is special: that you AV would run at CPU speed while the packers/unpackers will run at GPU speed. It would be like trying to catch a bank-robber who drives a Ferrari while riding your push-bike. Granted, you can still control the "roads", but control them too tight and I'll throw away your AV solution because it's making my computer run like on a 386/40 MHz on an everyday basis

Plus this kind of malware might be easier to deal with: Just shut down GPU processing. Unlike the CPU, that is a feasible thing to do. So if a system is infected, the GPU gets turned off, the malware cleaned, the GPU restarted. Graphics cards still work fine when addressed in old "Just a bunch of pixels," mode.

I imagine that a wise AV would use the GPU to actually run the unpacking and analysis/detection code faster.

Re:I fail to see how this is a big deal (1)

Sycraft-fu (314770) | about 4 years ago | (#33718492)

You are confused in to thinking GPUs are magical "everything acceleration" devices. Please remember if that were the case, we'd just use them as CPUs instead. It isn't the case. GPUs are special kinds of processors, called stream processors. There are only some things they are good at. Other things, they are much slower than CPUs. You also miss that the virus has to execute on the CPU first. There is no way, none, in Windows to directly execute on a GPU. Just not how the system works. You have to have a CPU process that then makes use of the GPU. So the virus has to come in, and then launch on the CPU, then it can unpack code to the GPU and execute it. The CPU process will still have to keep running the whole time, because that is how the system schedules resource time.

Again I fail to see what any of this gains. A virus scanner doesn't even need to look at the GPU to deal with this.

Oh and if your AV program is slow, go buy a better one. There are plenty of fast ones. I recommend reading AV comparatives and making your decision based on that.

Re:I fail to see how this is a big deal (1)

c0lo (1497653) | about 4 years ago | (#33720208)

You are confused in to thinking GPUs are magical "everything acceleration" devices.

Oh, am I now? That's incorrect, but I wonder what made you think so?

So the virus has to come in, and then launch on the CPU, then it can unpack code to the GPU and execute it. The CPU process will still have to keep running the whole time, because that is how the system schedules resource time.

With the minor correction that the CPU may be scheduled to other processes/threads (until the GPU finished and releases the lock on the memory), you are correct.

Again I fail to see what any of this gains. A virus scanner doesn't even need to look at the GPU to deal with this.

I never said the AV scanner would need to look at the GPU (only that would be advisable the AV scanner to use the GPU by itself).

I assert that the AV scanner cannot take any decision based solely on the behavior of "programs asks the GPU to do something then start executing from memory" and will need to look into the unpacked content to allow/disallow; fail to trap/hook this very moment and the scanner will loose the "race" (malware is already active).
The only way would be for the scanner act in "preventive mode" - unpack/emulate/analyse the piece before actually executing (at the "file open" or "file close" moment, that's how most of the Realtime AV scanners do) - well and fine if the "packing algo" is simple (and can be emulated on the CPU), hard if the packing algo is meant to use a GPU as an execution medium (if ignoring the fact, you will finish in using the CPU for a GPU job, which will slow the host computer).

Oh and if your AV program is slow, go buy a better one. There are plenty of fast ones. I recommend reading AV comparatives and making your decision based on that.

Many thanks for the advice, well intended but ineffective (I'm not using any, still safe most of the time and not contributing to global warming by paying tribute in wasted CPU cycles to AV solutions).

Re:I fail to see how this is a big deal (0)

Anonymous Coward | about 4 years ago | (#33720838)

If your GPU performs packing/polymorphism, you (the malware analyst) are unable to reasonably establish:

1) points where the packing/unpacking has started/finished
2) code segments that you can safely use for identifying malware
3) the algorithms and/or keys used during those transformations

Antivirus engines right now are indeed checking for packers. That is, packers that execute in the CPU. No antivirus engine, VM, emulator or otherwise instrumented environment currently takes the GPU into account as an execution environment..

Since you don't see anything wrong with it, I'd suggest listening to the facts from people with a more extensive knowledge of the area.

ATI (0)

Anonymous Coward | about 4 years ago | (#33716778)

It's a good thing I don't have 3D acceleration, yay my lack of open source drivers is finally starting to pay off.

Threats are not serious (2, Insightful)

dmitriy (40004) | about 4 years ago | (#33717598)

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.

Tradition (1)

yusing (216625) | about 4 years ago | (#33717634)

And why not - it's a time-honored tradition to make code run anywhere you can. Those who owned C64s (especially those who read Transactor) will recall that for a while there, programming the 1541 floppy-drive CPU was just about as cool as could be.

Nowadays systems are so complex, and tools to study them / keep an eye on them are so relatively clueless, there could be^H^H^H^H^H^H^H^H are dozens of things going on in our PCs that we are blissfully unaware of. Very unfortunate ... making things simple enough / safe enough for grandma has diminished / lulled many of us into blissful ignorance.

Harder (1)

Iggyhopper (1880812) | about 4 years ago | (#33718160)

It's harder, therefore effort vs reward is not good enough unless they have some good malware. Just slap some code into a PDF and you're all set.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?