Hacker News Reader

Comment by kibwen | Hacker News Reader

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.

View on HN

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

Define unfettered?

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

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.

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

Reply on news.ycombinator.com