Re: Timing attacks against CSS Shaders

Hi Adam,

I don't know much about timing attacks so I have a question.
Since the browser directs the GPU to run the shaders and composite their
output, the end result is invisible to the attacker since there is no
mechanism to get this bitmap data back.
The shaders also have no means to communicate through script  since they
can only manipulate pixels.

In this scenario, how would information ever leak?
WebGL is different since you have access to the entire OpenGL stack which
allows you to do more complex operations such as reading back data.

Rik

On Sat, Dec 3, 2011 at 11:23 PM, Adam Barth <w3c@adambarth.com> wrote:

> I spent some time looking at CSS Shaders, and they seem to suffer from
> a serious timing attack.  The details are described in this blog post,
> which I've reproduced (in part) below:
>
> http://www.schemehostport.com/2011/12/timing-attacks-on-css-shaders.html
>
> ===
>
> To understand the security problem with CSS Shaders, it's helpful to
> recall a recent security issue with WebGL.  Similar to CSS Shaders,
> WebGL lets developers use OpenGL shaders in their web applications.
> Originally, WebGL let these shaders operate on arbitrary textures,
> including textures fetched from other origins.  Unfortunately, this
> design was vulnerable to a timing attack because the runtime of OpenGL
> shaders can depend on their inputs.
>
> Using the shader code below, James Forshaw built a compelling
> proof-of-concept attack that extracted pixel values from a
> cross-origin image using WebGL:
>
> for (int i = 0; i <= 1024; i += 1) {
>  // Exit loop early depending on pixel brightness
>  currCol.r -= 1.0;
>  if (currCol.r <= 0.0) {
>    currCol.r = 0.0;
>    break;
>  }
> }
>
> Timing attacks are difficult to mitigate because once the sensitive
> data is present in the timing channel it's very difficult to remove.
> Using techniques like bucketing, we can limit the number of bits an
> attacker can extract per second, but, given enough time, the attacker
> can still steal the sensitive data.  The best solution is the one
> WebGL adopted: prevent sensitive data from entering the timing
> channel.  WebGL accomplished this by requiring cross-origin textures
> to be authorized via Cross-Origin Resource Sharing.
>
> There's a direct application of this attack to CSS Shaders.  Because
> web sites are allowed to display content that they are not allowed to
> read, an attacker can use a Forshaw-style CSS shader read confidential
> information via the timing channel.  For example, a web site could use
> CSS shaders to extract your identity from an embedded Facebook Like
> button.  More subtly, a web site could extract your browsing history
> bypassing David Baron's defense against history sniffing.
>
> The authors of the CSS Shaders proposal are aware of these issues.  In
> the Security Considerations section of their proposal, they write:
>
> ----8<----
> However, it seems difficult to mount such an attack with CSS shaders
> because the means to measure the time taken by a cross-domain shader
> are limited.
> ---->8----
>
> Now, I don't have a proof-of-concept attack, but this claim is fairly
> dubious.  The history of timing attacks, including other web timing
> attacks, teaches us that even subtle leaks in the timing channel can
> lead to practical attacks.  Given that we've seen practical
> applications of the WebGL version of this attack, it seems quite
> likely CSS Shaders are vulnerable to timing attacks.
>
> Specifically, there are a number of mechanisms for timing rendering.
> For example, MozBeforePaint and MozAfterPaint provide a mechanism for
> measuring paint times directly.  Also, the behavior of
> requestAnimationFrame contains information about rendering times.
>
> Without a proof-of-concept attack we cannot be completely certain that
> these attacks on CSS Shaders are practical, but waiting for
> proof-of-concept attacks before addressing security concerns isn't a
> path that leads to security.
>
> ===
>
> The blog post itself contains a number of citations to back up these
> claims.  Please let me know if you have any questions.
>
> Adam
>
>