Re: Documenting Timing Attacks in Rendering Engines

On Mon, Dec 12, 2011 at 8:38 AM, Vincent Hardy <> wrote:

> From: Adam Barth <>
> Date: Sat, 10 Dec 2011 00:37:56 -0800
> To: Adobe Systems <>
> Cc: "Tab Atkins Jr." <>, Charles Pritchard <
>>, "" <>
> 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:
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

Received on Monday, 12 December 2011 18:13:20 UTC