Re: Documenting Timing Attacks in Rendering Engines

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