TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

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

185 点作者 pedro84超过 6 年前

6 条评论

kibwen超过 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 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.
评论 #18450634 未加载
评论 #18450207 未加载
评论 #18453866 未加载
dahart超过 6 年前
&gt; 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).<p>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?<p>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.<p>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.
评论 #18452350 未加载
评论 #18450698 未加载
tomglynch超过 6 年前
I&#x27;m really into this trend of formal publications having clever puns in their titles.
评论 #18450081 未加载
评论 #18453378 未加载
评论 #18453723 未加载
nickpsecurity超过 6 年前
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&#x27;re concerned or want to be famous, there&#x27;s something you can do:<p>Shared Resource Matrix for Storage Channels (1983) <a href="http:&#x2F;&#x2F;www.cs.ucsb.edu&#x2F;~sherwood&#x2F;cs290&#x2F;papers&#x2F;covert-kemmerer.pdf" rel="nofollow">http:&#x2F;&#x2F;www.cs.ucsb.edu&#x2F;~sherwood&#x2F;cs290&#x2F;papers&#x2F;covert-kemmere...</a><p>Wray&#x27;s Extention for Timing Channels (1991) <a href="https:&#x2F;&#x2F;pdfs.semanticscholar.org&#x2F;3166&#x2F;161c3cbb5f8cd150d133a3746987da2d264d.pdf" rel="nofollow">https:&#x2F;&#x2F;pdfs.semanticscholar.org&#x2F;3166&#x2F;161c3cbb5f8cd150d133a3...</a><p>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 &quot;covert channels,&quot; &quot;side channels,&quot; &quot;non-interference proof or analysis,&quot; &quot;information flow analysis (or control),&quot; and &quot;information leaks.&quot; There&#x27;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! :)<p>Here&#x27;s an old Pastebin I did with examples of that:<p><a href="https:&#x2F;&#x2F;pastebin.com&#x2F;ajqxDJ3J" rel="nofollow">https:&#x2F;&#x2F;pastebin.com&#x2F;ajqxDJ3J</a>
ccnafr超过 6 年前
&quot;several vulnerabilities have already been demonstrated&quot;<p>Nothing in this paper is new, except a few tweaks here and there.<p>This is worrisome. More and more academic scientific research is the author taking previous research, adding a spin to it, and claiming it&#x27;s a new attack.
评论 #18451722 未加载
评论 #18451488 未加载
评论 #18451485 未加载
jotm超过 6 年前
Real world Spectre&#x2F;Meltdown when?