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

We don't allow drop shadow styling on visited links:
https://developer.mozilla.org/en/CSS/Privacy_and_the_:visited_selector
precisely
for this reason.

>
> 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 think this is a dead end from the start.  Obfuscating timing attacks
never eliminates them. Predictable noise is amazingly easy to remove from a
channel containing the signal and the noise. The timescales we are looking
at for normal operation are around 1/60th of a second and the potential
signal is orders of magnitude larger.  The way to defeat timing attacks is
to attack the signal, not attack the channel.

- James



>
> 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.
>
> May be I am just an optimist :-)
>

> Cheers,
> Vincent
>
>
>
>