Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

cs.ucr.edu

Post reply on HN
Print view View original

21–30 of 30 posts

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

#21

Post by IshKebab »

loeg wrote: post #20
EthanHeilman wrote: post #9

Earlier quoted context omitted.

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

If your sandbox gives unfettered access to the GPU, that's not a great sandbox, is it?

Erm.. Many sandboxes allow access to the GPU. E.g. WebGL or Android apps.

Why would you think otherwise?

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

#22

Post by [deleted] »

loeg wrote: post #20
EthanHeilman wrote: post #9

Earlier quoted context omitted.

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

If your sandbox gives unfettered access to the GPU, that's not a great sandbox, is it?

[deleted]

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

#24

Post by EthanHeilman »

loeg wrote: post #20
EthanHeilman wrote: post #9

Earlier quoted context omitted.

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

If your sandbox gives unfettered access to the GPU, that's not a great sandbox, is it?

Define unfettered?

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

#27

Post by kllrnohj »

kibwen wrote: post #6

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…

Reading the attack it also only seems to work on browsers that are not doing very good GPU rendering. The process they described, a textbox being rendered on the CPU and uploaded to a texture on every update, is terribly inefficient. That's not what, for example, Android's text renderer does (described in detail here: https://medium.com/@romainguy/androids-font-renderer-c368bbd... )

If the renderer uses a glyph atlas, then there won't be any changes in GPU memory used as you type in a text box. There consequently won't be any time used to update glyphs, as they are already in the atlas (ignoring CJK locales for a minute).

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

#28

Post by somebodythere »

Sohcahtoa82 wrote: post #25
tomglynch wrote: post #2

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

Definitely better than the cliche "_______ considered harmful" or "_______ 2: Electric Boogaloo"

"The Unreasonable Effectiveness of _______"

"_______ is All You Need"

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

#29

Post by logicchains »

pcwalton wrote: post #18
dahart wrote: post #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…

> 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 u…

I heard apart from Gecko most browsers still use immediate mode for rendering, which is insanely inefficient and does no caching.

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

#30

Post by DiabloD3 »

monocasa wrote: post #16
kangz wrote: post #7

Earlier quoted context omitted.

> 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…

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?

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.
Post reply on HN