- From: Ralph Thomas <ralpht@gmail.com>
- Date: Sun, 4 Dec 2011 11:35:20 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: Rik Cabanier <cabanier@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, public-fx@w3.org, Dean Jackson <dino@apple.com>, Vincent Hardy <vhardy@adobe.com>, Thomas Roessler <tlr@w3.org>
Until there is a strategy on preventing timing leaks, is there a way you could change the content being shaded to not include sensitive information (no external iframes, no :visited on links going to other domains, no external-domain images [or none that needed cookies/auth/etc to fetch])? Kind of like XHR is careful not to fetch things it shouldn't. Ralph On Sun, Dec 4, 2011 at 11:07 AM, Adam Barth <w3c@adambarth.com> wrote: > On Sun, Dec 4, 2011 at 10:51 AM, Ralph Thomas <ralpht@gmail.com> > wrote: >> Would it be possible to disable CSS shaders on a page which uses them >> and takes too long to composite? The goal of CSS shaders is visually >> rich _interactive_ experiences, so you could probably make the >> threshold low enough (100ms?) that timing attacks would be much harder >> -- especially if rAF is rounded to the vblank interval... Depending on >> where rendering takes place, the attacker might still have one full >> iteration of the slow shader to measure though. > > Generally, approaches like that have been tried in many other settings > to stop or slow leaks in the timing channel. They've generally been > unsuccessful in those settings, but that doesn't mean they'll > necessarily be in successful in our setting. > > The problem with these sorts of approaches is it's difficult to > actually stop the information leak. You can only slow it down. For > example, if you requires the page to render at some fixed frame rate, > what happens when the page takes too long to render? You'll end up > doing something different, and that difference is likely observable to > the attacker, leaking one bit of data. It doesn't take very many bits > of data before the attacker can extract text, for example, in a > cross-origin iframe. In some case, for example history sniffing, the > attacker is only looking for one bit: did the user visit my > competitor's web site. > > On Sun, Dec 4, 2011 at 10:58 AM, Rik Cabanier <cabanier@gmail.com> wrote: >> Thanks for the link! >> The webkit discussion also has some good info. >> So, the combination of requestAnimationFrame and changing the duration of a >> compositing operation in response to a pixel color, gives you the ability to >> harvest information. > > I wouldn't focus too much on requestAnimationFrame. Once the > sensitive data is in the timing channel, it's likely to be observable > via other mechanisms. > >> Does the browser wait for the GPU to stop compositing or does it upload the >> drawing commands and lets the GPU do the compositing asynchronously? > > It doesn't really matter. Even if all the drawing takes place > asynchronously, at some point the pipeline will be full, which is > likely observable to the attacker as a dropped frame. Another way to > think about this is if the attacker can "keep the GPU busy", then he > or she might be able to observe that WebGL operations take longer. > > Adam > > >> On Sun, Dec 4, 2011 at 10:16 AM, Tab Atkins Jr. <jackalmage@gmail.com> >> wrote: >>> >>> On Sun, Dec 4, 2011 at 10:04 AM, Rik Cabanier <cabanier@gmail.com> wrote: >>> > Hi Adam, >>> > >>> > I don't know much about timing attacks so I have a question. >>> > Since the browser directs the GPU to run the shaders and composite their >>> > output, the end result is invisible to the attacker since there is no >>> > mechanism to get this bitmap data back. >>> > The shaders also have no means to communicate through script since they >>> > can >>> > only manipulate pixels. >>> > >>> > In this scenario, how would information ever leak? >>> > WebGL is different since you have access to the entire OpenGL stack >>> > which >>> > allows you to do more complex operations such as reading back data. >>> >>> The information is read back through the "timing channel", thus the >>> name. This is done by making an operation take more or less time >>> based on the information you want to extract, so you can read data out >>> just by watching how long an operation took to complete, even if the >>> language doesn't offer any way to get the data out normally. >>> http://en.wikipedia.org/wiki/Timing_attack >>> >>> ~TJ >> >> >
Received on Sunday, 4 December 2011 19:35:51 UTC