6 ms·

Rendered Insecure: GPU Side Channel Attacks Are Practical [pdf]

185 points by pedro84 8y ago

tomglynch 8y ago
I'm really into this trend of formal publications having clever puns in their titles.
- izietto 8y ago
  Can you explain the pun? I'm not english and I'm struggling getting it EDIT: ohh is it maybe that one meaning of "render" is "make"? So it's like "made insecure"?
  - appleflaxen 8y ago
    "rendered" as in graphical rendering (painting) of a scene (vs the more direct meaning of "being made" insecure).
  - cosarara 8y ago
    > ohh is it maybe that one meaning of "render" is "make"? So it's like "made insecure"? It's exactly that, yes.
- Sohcahtoa82 8y ago
  Definitely better than the cliche "_______ considered harmful" or "_______ 2: Electric Boogaloo"
  - somebodythere 8y ago
    "The Unreasonable Effectiveness of _______" "_______ is All You Need"
- ktta 8y ago
  You're in luck https://news.ycombinator.com/item?id=18442578 https://news.ycombinator.com/item?id=18442578
kibwen 8y ago
The browser password capture attack is awesome. To clarify though, that requires an external attacker-controlled process to monitor the GPU, yes? If you've already got a process running on the victim's computer, aren't there easier ways of installing a keylogger? Alternatively, are there legitimate programs that grant the ability to run arbitrary untrusted GPU code (WebGL springs to mind, but you'd think that if this attack were possible entirely from within the browser that they'd have been eager to show it off)? Or is the novelty here the ability to more easily guess which keystrokes represent passwords due to the website fingerprinting step? In any case, it suggests that websites could slightly frustrate the attack by making all the textboxes on their login page the same size, and that anyone using any password manager, including the one built in to their browser, is largely protected. Very cool nonetheless.
- kangz 8y ago
  > To clarify though, that requires an external attacker-controlled process to monitor the GPU, yes? Yes, they do it with high-speed probing of the amount allocated GPU memory. This requires access to native APIs (specific OpenGL extensions in this case). Like you said there seems there would be simpler ways to achieve this, but the demonstration of this side-channel is still very interesting. Varying the size of the textboxes might not help because the rendering engine of browsers can have a memory allocation per letter for example.
  - monocasa 8y ago
    Last time I checked on Vulkan, you took a lot of GPU memory allocation into your own hands. You allocate large chunks that you then write your own allocator for to carve up (sort of like the distinction between sbrk/mmap and malloc). Is that still the case, and would that unintentionally avoid this side channel since the global GPU perf stats wouldn't necessarily see a difference on small allocations?
    - DiabloD3 8y ago
      That's not entirely true, and that's basically what all modern games do: switching buffers is an expensive context switch, so texture atlasses became the norm over a decade ago, as did stuffed vertex buffers.
dahart 8y ago
> By probing the GPU memory allocation repeatedly, we can detect the pattern of user typing (which typically causes re-rending of the textbox or similar structure animating the characters). I guess I’m a tiny bit surprised that the browsers are de-allocating and re-allocating memory for the re-render of the text box elements, since they don’t change size. Presumably this would be texture memory? Does anyone here know precisely what’s happening there, and whether a render-to-texture won’t work for some reason? Is it normal for browsers to allocate memory for all element repaints, or is this something unique to text typing or font handling? The paper mentioned some mitigation avenues from the GPU’s perspective, but there are easy mitigations from the browser side here too. Given their interest in security, it seems reasonable for browsers to move on easy mitigations without waiting for changes to the GPU API. Rate limiting password fields in the browser, and avoiding GPU memory allocations while the user is only typing into a small text box element would remove the ability to do timing attacks on passwords. Individual websites can even do these things if they’re worried about it.
- Chabs 8y ago
  Speculation: GPU-based text rendering is typically going to be done using two triangles per glyph. So what they are seeing is probably not the allocation of the underlying texture storage, but the transient vertex buffer that contains the information of which glyph to render and where to render them.
  - dahart 8y ago
    Interesting, that sounds plausible and reasonable, except that the authors mention the minimum granularity of memory reporting is 128KB blocks. For this attack to work, the response to a keystroke has to reliably allocate more than 128KB every time. The vertex and index buffers for a pair of triangles is less than 100 bytes, right? So if only geometry were allocated, you'd only see measurable allocations every once in a while and not for every keystroke. What else might be getting allocated?
  - pcwalton 8y ago
    Well, most GPU-based painting backends would try to recycle those VBOs to avoid reallocating them every frame. But it's hard to get all the heuristics right; cache invalidation is one of the two hard problems of computer science, after all…
ccnafr 8y ago
"several vulnerabilities have already been demonstrated" Nothing in this paper is new, except a few tweaks here and there. This is worrisome. More and more academic scientific research is the author taking previous research, adding a spin to it, and claiming it's a new attack.
- khawkins 8y ago
  "More and more academic scientific research is the author taking previous research, adding a spin to it, and claiming it's...new" This describes the vast majority of academic publications both today and a few decades ago. It might not be worthy of spotlight, but there is certainly a place for it in academia.
- busterarm 8y ago
  This describes probably half of the research or talks I've seen presented from the infosec industry. Go to infosec meetups like Empire Hacking (the Trail of Bits meetup) and this will be almost every talk without exception. It's an industry that runs on social capital and people have to do anything to get their name out there. Fortunately there is still good work being done.
- stcredzero 8y ago
  More and more academic scientific research is the author taking previous research, adding a spin to it, and claiming it's a new attack. This is nothing new. There was a period of time when it seemed like all CompSci papers had to do with some variation on hashing. There was a period of time at OOPSLA where it seemed like some whopping big fraction of papers was just a Java port of something that had been done in Smalltalk several years before. "Publish or perish," is just academia's version of YouTubers posting 3 videos a week.
nickpsecurity 8y ago
Repeat after me the lesson from the founders of information security: every system, from individual components to their integration, is insecure until proven trustworthy by sufficient analysis. You have to also have a precise statement of what secure means to compare the system against. You then apply methods proven to work for various classes of problems. By 1992, they had found everything from kernel compromises to cache-based, timing channels using such methods. On this topic, every hardware and software component in every centralized or decentralized system has covert channels leaking your secrets. Now, if you're concerned or want to be famous, there's something you can do: Shared Resource Matrix for Storage Channels (1983) http://www.cs.ucsb.edu/~sherwood/cs290/papers/covert-kemmerer.pdf http://www.cs.ucsb.edu/~sherwood/cs290/papers/covert-kemmere... Wray's Extention for Timing Channels (1991) https://pdfs.semanticscholar.org/3166/161c3cbb5f8cd150d133a3746987da2d264d.pdf https://pdfs.semanticscholar.org/3166/161c3cbb5f8cd150d133a3... Using such methods were mandatory under the first, security regulations called TCSEC. They found a lot of leaks. High-assurance, security researchers stay improving on this with some trying to build automated tools to find leaks in software and hardware. Buzzwords include "covert channels," "side channels," "non-interference proof or analysis," "information flow analysis (or control)," and "information leaks." There's even programming languages designed to prevent accidental leaks in the app or do constant-time implementations for stuff like crypto. Go forth and apply covert-channel analysis and mitigation on all the FOSS things! :) Here's an old Pastebin I did with examples of that: https://pastebin.com/ajqxDJ3J https://pastebin.com/ajqxDJ3J
jotm 8y ago
Real world Spectre/Meltdown when?

185 points by pedro84 8y ago

tomglynch 8y ago

I'm really into this trend of formal publications having clever puns in their titles.

izietto 8y ago
Can you explain the pun? I'm not english and I'm struggling getting it EDIT: ohh is it maybe that one meaning of "render" is "make"? So it's like "made insecure"?
- appleflaxen 8y ago
  "rendered" as in graphical rendering (painting) of a scene (vs the more direct meaning of "being made" insecure).
- cosarara 8y ago
  > ohh is it maybe that one meaning of "render" is "make"? So it's like "made insecure"? It's exactly that, yes.
Sohcahtoa82 8y ago
Definitely better than the cliche "_______ considered harmful" or "_______ 2: Electric Boogaloo"
- somebodythere 8y ago
  "The Unreasonable Effectiveness of _______" "_______ is All You Need"
ktta 8y ago
You're in luck https://news.ycombinator.com/item?id=18442578 https://news.ycombinator.com/item?id=18442578

kibwen 8y ago

The browser password capture attack is awesome. To clarify though, that requires an external attacker-controlled process to monitor the GPU, yes? If you've already got a process running on the victim's computer, aren't there easier ways of installing a keylogger? Alternatively, are there legitimate programs that grant the ability to run arbitrary untrusted GPU code (WebGL springs to mind, but you'd think that if this attack were possible entirely from within the browser that they'd have been eager to show it off)? Or is the novelty here the ability to more easily guess which keystrokes represent passwords due to the website fingerprinting step? In any case, it suggests that websites could slightly frustrate the attack by making all the textboxes on their login page the same size, and that anyone using any password manager, including the one built in to their browser, is largely protected. Very cool nonetheless.

kangz 8y ago
> To clarify though, that requires an external attacker-controlled process to monitor the GPU, yes? Yes, they do it with high-speed probing of the amount allocated GPU memory. This requires access to native APIs (specific OpenGL extensions in this case). Like you said there seems there would be simpler ways to achieve this, but the demonstration of this side-channel is still very interesting. Varying the size of the textboxes might not help because the rendering engine of browsers can have a memory allocation per letter for example.
- monocasa 8y ago
  Last time I checked on Vulkan, you took a lot of GPU memory allocation into your own hands. You allocate large chunks that you then write your own allocator for to carve up (sort of like the distinction between sbrk/mmap and malloc). Is that still the case, and would that unintentionally avoid this side channel since the global GPU perf stats wouldn't necessarily see a difference on small allocations?
  - DiabloD3 8y ago
    That's not entirely true, and that's basically what all modern games do: switching buffers is an expensive context switch, so texture atlasses became the norm over a decade ago, as did stuffed vertex buffers.

dahart 8y ago

> By probing the GPU memory allocation repeatedly, we can detect the pattern of user typing (which typically causes re-rending of the textbox or similar structure animating the characters). I guess I’m a tiny bit surprised that the browsers are de-allocating and re-allocating memory for the re-render of the text box elements, since they don’t change size. Presumably this would be texture memory? Does anyone here know precisely what’s happening there, and whether a render-to-texture won’t work for some reason? Is it normal for browsers to allocate memory for all element repaints, or is this something unique to text typing or font handling? The paper mentioned some mitigation avenues from the GPU’s perspective, but there are easy mitigations from the browser side here too. Given their interest in security, it seems reasonable for browsers to move on easy mitigations without waiting for changes to the GPU API. Rate limiting password fields in the browser, and avoiding GPU memory allocations while the user is only typing into a small text box element would remove the ability to do timing attacks on passwords. Individual websites can even do these things if they’re worried about it.

Chabs 8y ago
Speculation: GPU-based text rendering is typically going to be done using two triangles per glyph. So what they are seeing is probably not the allocation of the underlying texture storage, but the transient vertex buffer that contains the information of which glyph to render and where to render them.
- dahart 8y ago
  Interesting, that sounds plausible and reasonable, except that the authors mention the minimum granularity of memory reporting is 128KB blocks. For this attack to work, the response to a keystroke has to reliably allocate more than 128KB every time. The vertex and index buffers for a pair of triangles is less than 100 bytes, right? So if only geometry were allocated, you'd only see measurable allocations every once in a while and not for every keystroke. What else might be getting allocated?
- pcwalton 8y ago
  Well, most GPU-based painting backends would try to recycle those VBOs to avoid reallocating them every frame. But it's hard to get all the heuristics right; cache invalidation is one of the two hard problems of computer science, after all…

ccnafr 8y ago

"several vulnerabilities have already been demonstrated" Nothing in this paper is new, except a few tweaks here and there. This is worrisome. More and more academic scientific research is the author taking previous research, adding a spin to it, and claiming it's a new attack.

khawkins 8y ago
"More and more academic scientific research is the author taking previous research, adding a spin to it, and claiming it's...new" This describes the vast majority of academic publications both today and a few decades ago. It might not be worthy of spotlight, but there is certainly a place for it in academia.
busterarm 8y ago
This describes probably half of the research or talks I've seen presented from the infosec industry. Go to infosec meetups like Empire Hacking (the Trail of Bits meetup) and this will be almost every talk without exception. It's an industry that runs on social capital and people have to do anything to get their name out there. Fortunately there is still good work being done.
stcredzero 8y ago
More and more academic scientific research is the author taking previous research, adding a spin to it, and claiming it's a new attack. This is nothing new. There was a period of time when it seemed like all CompSci papers had to do with some variation on hashing. There was a period of time at OOPSLA where it seemed like some whopping big fraction of papers was just a Java port of something that had been done in Smalltalk several years before. "Publish or perish," is just academia's version of YouTubers posting 3 videos a week.

nickpsecurity 8y ago

Repeat after me the lesson from the founders of information security: every system, from individual components to their integration, is insecure until proven trustworthy by sufficient analysis. You have to also have a precise statement of what secure means to compare the system against. You then apply methods proven to work for various classes of problems. By 1992, they had found everything from kernel compromises to cache-based, timing channels using such methods. On this topic, every hardware and software component in every centralized or decentralized system has covert channels leaking your secrets. Now, if you're concerned or want to be famous, there's something you can do: Shared Resource Matrix for Storage Channels (1983) http://www.cs.ucsb.edu/~sherwood/cs290/papers/covert-kemmerer.pdf http://www.cs.ucsb.edu/~sherwood/cs290/papers/covert-kemmere... Wray's Extention for Timing Channels (1991) https://pdfs.semanticscholar.org/3166/161c3cbb5f8cd150d133a3746987da2d264d.pdf https://pdfs.semanticscholar.org/3166/161c3cbb5f8cd150d133a3... Using such methods were mandatory under the first, security regulations called TCSEC. They found a lot of leaks. High-assurance, security researchers stay improving on this with some trying to build automated tools to find leaks in software and hardware. Buzzwords include "covert channels," "side channels," "non-interference proof or analysis," "information flow analysis (or control)," and "information leaks." There's even programming languages designed to prevent accidental leaks in the app or do constant-time implementations for stuff like crypto. Go forth and apply covert-channel analysis and mitigation on all the FOSS things! :) Here's an old Pastebin I did with examples of that: https://pastebin.com/ajqxDJ3J https://pastebin.com/ajqxDJ3J

jotm 8y ago

Real world Spectre/Meltdown when?