- From: Adam Barth <w3c@adambarth.com>
- Date: Mon, 12 Dec 2011 10:23:16 -0800
- To: Vincent Hardy <vhardy@adobe.com>
- Cc: "public-fx@w3.org" <public-fx@w3.org>
On Mon, Dec 12, 2011 at 8:38 AM, Vincent Hardy <vhardy@adobe.com> wrote: > From: Adam Barth <w3c@adambarth.com> > Date: Sat, 10 Dec 2011 00:37:56 -0800 > To: Adobe Systems <vhardy@adobe.com> > Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Charles Pritchard > <chuck@jumis.com>, "public-fx@w3.org" <public-fx@w3.org> > Subject: Re: Documenting Timing Attacks in Rendering Engines > > Thanks for sharing the information from the F2F. Unfortunately, at > this time, I'm not aware of any solutions to this problem. CORS is > insufficient and mandating "that UAs do not give out information on > rendered content from timing", while a laudable goal, isn't possible > to implement. > > > Hi Adam, > > I think the problem already exists regardless of shaders. > > We already have filter effects on SVG content (which may include HTML > through foreignObjects). They can impact the rendering time of content. And > regardless of shaders / filters, it is possible to modify content and > compute the rendering time to detect patterns. > > I'll take a silly and extreme case. If an attacker finds that the rendering > of a visited link took a lot more time than rendering a non visited link, > he/she could find out, through timing, if a url had been visited by the > victim. No shaders involved. May be the attacker just added a very large > number of drop shadows to the style of visited links or something else that > also impacted rendering. > > So since we have leakage of information by timing the rendering, I think we > need to understand how bad the problem/threat is. As discussed before, > shaders and filters may accentuate the issue (because they can slow down > rendering of specific colors etc...) but the core issue, I think, is that > timing the rendering (in general) leaks information. May be we should find > how to obfuscate timing in requestAnimationFrame so that information leakage > is reduced/removed. I think Dean has ideas there. I've responded to all of these points earlier. > I like to think that there are solutions to problems, even though not > obvious at first :-). We may apply restrictions where needed. For example, I > think CORS addresses some of the issues. Let's try to find out solutions to > the other issues. I'm happy to start talking about solutions once folks stop pretending this vulnerability doesn't exist. Adam
Received on Monday, 12 December 2011 18:29:38 UTC