[webkit-dev] Timing attacks on CSS Shaders (was Re: Security problems with CSS shaders)

Charles Pritchard chuck at jumis.com
Sun Dec 4 00:30:44 PST 2011


On 12/3/11 11:06 PM, Adam Barth wrote:
> On Mon, Oct 24, 2011 at 9:51 PM, Adam Barth<abarth at webkit.org>  wrote:
>> Personally, I don't believe it's possible to implement this feature
>> securely, at least not using the approach prototyped by Adobe.
>> However, I would love to be proven wrong because this is certainly a
>> powerful primitive with many use cases.
> I spent some more time looking into timing attacks on CSS Shaders.  I
> haven't created a proof-of-concept exploit, but I believe the current
> design is vulnerable to timing attacks.  I've written up blog post
> explaining the issue:
>
> http://www.schemehostport.com/2011/12/timing-attacks-on-css-shaders.html
>
> Jonas Sicking seems to have a similar concern:
>
> https://twitter.com/#!/SickingJ/status/143161375823380480
>
> It's probably worth addressing this concern sooner rather than later.
> Ignoring it certainly won't cause the vulnerability to go away.

What was the verdict on CORS + Web Fonts? As I understood things, they 
were introduced for cross domain use (much like WebGL) and that's been 
an issue that I think vendors are peddling back on. I'm fully supportive 
of discovering just what the relative security issues are here... While 
that's going on: it seems like this feature can be made CORS-aware in 
subsequent prototypes while we wait on a verdict about timing issues.

I'm bringing up fonts, as they'd be the first [that I'm aware of] 
technology where CSS has integrated CORS.

There are many -many-many- quirks that authors will have to deal with, 
with programmable shaders. If everything were restricted to the CPU, 
we'd know that well, low end systems run with 1ghz and high end systems 
have multiple cores, but the performance and compatibility spread is 
something reasonable. Once GPUs are in the mix, we're talking about a 
100x difference, we're talking about all sorts of visual glitches, it's 
a mess.

I'm very much for getting this CSS shader proposal through. Between 
object-fit (and some other values) and custom shaders, I could rid 
myself of a thousand lines of code handling some basic image 
manipulation tasks. There are benefits to developers to weigh with the 
risks. I would be willing to accept CORS+CSS shaders as a compromise. 
There are  good opt-out mechanisms for secure sites; HTTP headers for 
nosniff and the like.

I do think the security issues that Dean Jackson has brought up are 
fascinating. It does seem to me that documenting attacks of various 
sorts is a worthwhile venture. I see it happening in a manner similar to 
how WCAG-TECHS exists. I don't think that those documented attacks spell 
doom.

Anecdote: I brought up Web Storage to the postgresql hackers mailing 
list awhile back. At least one developer was absolutely aghast that 
sites could launch attacks by creating thousands of 5 megabyte storage 
entries. The 5 meg per-origin limit works in practice, but explaining 
that fact was difficult.

There seems to be broad consensus/desire for facts about known attack 
vectors. I think it'd benefit all interested parties if something were 
created, in the style of WCAG-TECHS. http://www.w3.org/TR/WCAG-TECHS/

Such as, "Techniques and Failures for Web Security".





More information about the webkit-dev mailing list