Rendered Insecure: GPU Side Channel Attacks Are Practical [pdf]
1–10 of 30 posts
Re: Rendered Insecure: GPU Side Channel Attacks Are Practical [pdf]
#2I'm really into this trend of formal publications having clever puns in their titles.
Re: Rendered Insecure: GPU Side Channel Attacks Are Practical [pdf]
#3I'm really into this trend of formal publications having clever puns in their titles.
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"?
Re: Rendered Insecure: GPU Side Channel Attacks Are Practical [pdf]
#4I'm really into this trend of formal publications having clever puns in their titles.
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"?
"rendered" as in graphical rendering (painting) of a scene (vs the more direct meaning of "being made" insecure).
Re: Rendered Insecure: GPU Side Channel Attacks Are Practical [pdf]
#5I'm really into this trend of formal publications having clever puns in their titles.
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"?
> ohh is it maybe that one meaning of "render" is "make"? So it's like "made insecure"?
It's exactly that, yes.
Re: Rendered Insecure: GPU Side Channel Attacks Are Practical [pdf]
#6The 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.
Re: Rendered Insecure: GPU Side Channel Attacks Are Practical [pdf]
#7The 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…
> 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.
Re: Rendered Insecure: GPU Side Channel Attacks Are Practical [pdf]
#8> 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.
Re: Rendered Insecure: GPU Side Channel Attacks Are Practical [pdf]
#9The 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…
>If you've already got a process running on the victim's computer, aren't there easier ways of installing a keylogger?
Now system designers have to very seriously consider this risk when building sandboxes or other forms of process isolation. Say the attacker controlled process is in a sandbox and would normally be assumed safe.
Re: Rendered Insecure: GPU Side Channel Attacks Are Practical [pdf]
#10> 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…
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.