On 12/3/11 11:06 PM, Adam Barth wrote:
On Mon, Oct 24, 2011 at 9:51 PM, Adam Barth<aba...@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".
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
