Re: Documenting Timing Attacks in Rendering Engines

Sorry if my previous response came off as abrupt.  Let me try replying
to your message again.

On Mon, Dec 12, 2011 at 8:38 AM, Vincent Hardy <vhardy@adobe.com> wrote:
> I think the problem already exists regardless of shaders.

These issues would exist regardless of shaders if we weren't careful
about maintaining this security property throughout the platform, but
there's been a bunch of careful work done by many folks over a number
of years to plug these sorts of leaks.  For example, David Baron
considered and experimented with timing attacks when he proposed and
implemented his history sniffing defense, and that's what motivated
his choices of which CSS properties could differ between visited and
non-visited links.  Folk have also analyzed other side channels (e.g.,
http://websec.sv.cmu.edu/visited/visited.pdf), so we have a pretty
good handle on what is and what is not possible.

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

If that's possible, I'd encourage you to report the vulnerability to
the various vendors (e.g.,
http://www.chromium.org/Home/chromium-security/reporting-security-bugs)
in a responsible manner.  These reports will likely qualify for
rewards via Chromium and Mozilla's vulnerability rewards programs.

Note you'll need to construct a filter effect that has a different
running time based only on the color of the hyperlink.  Other CSS
properties are forbidden from varying between visited and non-visited
hyperlinks.  That's easy to do with a CSS Shader, but it's unclear to
me how to do that without a shader.

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

Yes, that would be a vulnerability.  As far as I know, no one knows
how to do that without shaders.  We do know how to do this if we could
apply different effects (such as drop shadows) to visited and
non-visited hyperlinks, but, as James says, that is forbidden.

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

That approach is unlikely to be successful.  Once the information has
entered the timing channel, it's basically impossible to remove.  You
can try to hide the information with blocking or noise, but experience
in many other domains tells us that these mitigations are surprisingly
easy for attackers to circumvent.

The only approach I'm aware of that has a chance of success is to
prevent the sensitive information from entering the timing channel in
the first place.

> 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 :-)

If you have a specific proposal, I'm happy to review it.  So far I
haven't seen a proposal that wasn't trivially broken.  Specifically
for the approach you mention above, relying upon CORS does not address
the history sniffing risk.

Adam

Received on Monday, 12 December 2011 19:27:13 UTC