[Webkit-unassigned] [Bug 69044] Canvas drawElement() security issues

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=69044





--- Comment #18 from Matthew Delaney <mdelaney at apple.com>  2011-09-30 12:52:26 PST ---
(In reply to comment #17)
> > I was referring to the security issue of drawImage(). Unless I've been mistaken this whole time, the attack that Philip demonstrated (one example at http://philip.html5.org/demos/canvas/img-timing-1.html) is possible currently.
> 
> Yeah, but that attack is public.  As far as I can tell, there's no need for secrecy.

Gotcha. Like I said, I have no problem moving it out. I was just avoiding making anyone upset.


> > Ok. So just to be clear, your main concern is making the hole wider then, right? If that's the case, I'm wondering how severe people view leaking secure image/video data is compared to other data such as visited links.
> 
> They're vulnerabilities of a different kind.  Currently, the only known techniques for exploit drawImage reveal the alpha channel of cross-origin images.  That attack hasn't lit the world on fire because there aren't all that many secrets stored in the alpha channels of images.
> 
> By contrast, people are quite sensitive about their visited link history.  When that information was exposed directly in the DOM, it triggered articles in the New York Times and other mainstream publications.  The Davids Baron and Hyatt put a lot of thought and effort into mitigating that issue.  We certainly don't want to undo that work.

Right, of course not. I'm assuming that's why links were limited to only using opaque colors, right?

For this, we could avoid the issue altogether by not honoring the visited color of the links when rendering.   Just an idea.

I fully realize that this kind of feature can get messy very quickly and have many edge cases. Blacklisting is scary because it's hard to identify all current problems, adding elements later could break content that relies on this feature, and we'd have to update it for all future elements. Whitelisting allows us to only allow elements we've deemed safe and doesn't have the issue of introducing leaks via new elements, however it doesn't protect us if a whitelisted element is later proven to be unsafe.

Adam, should we just continue on the public bug then? Hopefully we don't inadvertently brew up any exploit ideas from discussing this feature that somehow affect any current features ;-)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.