Re: [webkit-dev] Security problems with CSS shaders (was Re: Starting implementation on W3C Filter Effects)
On Tue, Oct 25, 2011 at 10:07 AM, Dean Jackson wrote: > On 25/10/2011, at 9:49 AM, Adam Barth wrote: >>> Adam's point in the bug is that any operation that can access colour >>> channels might be able to perform a timing attack. This would include SVG >>> filters operating on HTML content without any hardware acceleration. >>> >>> For this reason I'm still tempted to suggest the combination of CSS_FILTERS >>> + WEBGL is enough of a switch for ports to disable this, but I'm happy to >>> add another one. >>> >>> I'm not sure at what point we should take the discussion from this list and >>> onto bugzilla. >> >> I don't believe you understand the security issue. I'd recommend you >> seek the advice of security experts to help you make this decision. > > OK, I'll make sure CSS Shaders has a separate flag which allows ports to turn > it off. But you'll still be susceptible to the same problems with > CSS_FILTERS, and with the current implementation of SVG filters that you > support. Thanks. I'll flag CSS_FILTERS for further security review. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Security problems with CSS shaders (was Re: Starting implementation on W3C Filter Effects)
On 25/10/2011, at 9:49 AM, Adam Barth wrote: >> Adam's point in the bug is that any operation that can access colour >> channels might be able to perform a timing attack. This would include SVG >> filters operating on HTML content without any hardware acceleration. >> >> For this reason I'm still tempted to suggest the combination of CSS_FILTERS >> + WEBGL is enough of a switch for ports to disable this, but I'm happy to >> add another one. >> >> I'm not sure at what point we should take the discussion from this list and >> onto bugzilla. > > I don't believe you understand the security issue. I'd recommend you > seek the advice of security experts to help you make this decision. OK, I'll make sure CSS Shaders has a separate flag which allows ports to turn it off. But you'll still be susceptible to the same problems with CSS_FILTERS, and with the current implementation of SVG filters that you support. Dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Security problems with CSS shaders (was Re: Starting implementation on W3C Filter Effects)
On Tue, Oct 25, 2011 at 3:14 AM, Dirk Schulze wrote: > Am 24.10.2011 um 21:51 schrieb Adam Barth: >>> I'd like to know what the actual threat of such timing attacks are. I've >>> seen claims of a maximum theoretical leak rate (in bits/s) but then counter >>> claims that since, in this case, it would be hard to distinguish the >>> difference in slowdown between CSS shaders and general page rendering, that >>> the real rate is much lower. And, at least in the case of Safari, you can't >>> always be sure that getting a rAF callback means you're about to draw. >>> >>> Does anyone have hard data on this? > >> At a minimum, please do not land an implementation for this feature >> without a way for ports that are concerned about this security feature >> to disable it independently of both CSS_FILTERS and WEBGL. Contrary >> to your previous assertion, the security implications are quite >> different than those with WebGL. > > We already discussed the HW acceleration of SVG Filters > on https://bugs.webkit.org/show_bug.cgi?id=70099 and the implementation of > CSS Filters earlier on this mailing list. We agreed that we will continue to > use the implemented software rendering as fallback for Filters. CSS Shaders > won't be included. Shaders should just be supported if HW acceleration is > enabled. And I think as a minimum consensus on bug 70099 most people on the > thread agreed to go on with GraphicsContext3D for now. In my opinion it > means we would have the same security concerns like on WebGL. I don't believe that's correct. The issue I described above arises only when we run shaders authored by the web site on content rendered by WebCore. Can you explain how to conduct the attacks I'm worried about using HW accelerated SVG Filters or WebGL? > That's also > one reason why I think that the WEBGL flag would match these needs quite > well, even if CSS Shaders rely just indirectly to WebGL. If the flag is not > enabled, CSS Shaders are deactivated (and ignored if web developers use them > in their filter chain) and Filters take the software rendering fallback. I'll repeat what I wrote before (edited for grammar): 8< At a minimum, please do not land an implementation of this feature without a way for ports that are concerned about this security issue to disable it independently of both CSS_FILTERS and WEBGL. Contrary to your previous assertion, the security implications are quite different than those with WebGL. >8 If you'd like to experiment with this feature, I have no desire to prevent you from doing that. I'm just asking that you not force other ports to ship security vulnerabilities to their customers. I'd also recommend that you do a security review of this feature--with this concern in mind---because I'm fairly confident you'll find that you'll need to redesign the API significantly before other browser vendors will be willing to implement it. On Tue, Oct 25, 2011 at 8:43 AM, Dean Jackson wrote: > Sorry, I was assuming a WebGL that allowed input from > canvasContext.drawElement. At that point I think they are close enough to > call the same (no doubt I'm wrong! :) Even without drawElement, WebGL offers > a lot of attack vectors. That might or might not be true, but it doesn't offer *this* attack vector. Security is a multidimensional property, hence the "vector" terminology. For various reasons, a number of browser vendors have decided to accept whatever risks implementing WebGL poses. They have not, however, decided whether to accept the different risks posed by CSS shaders. I'm just asking for the ability to make that decision myself. On Tue, Oct 25, 2011 at 8:43 AM, Dean Jackson wrote: > Adam's point in the bug is that any operation that can access colour channels > might be able to perform a timing attack. This would include SVG filters > operating on HTML content without any hardware acceleration. > > For this reason I'm still tempted to suggest the combination of CSS_FILTERS + > WEBGL is enough of a switch for ports to disable this, but I'm happy to add > another one. > > I'm not sure at what point we should take the discussion from this list and > onto bugzilla. I don't believe you understand the security issue. I'd recommend you seek the advice of security experts to help you make this decision. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Security problems with CSS shaders (was Re: Starting implementation on W3C Filter Effects)
On 25/10/2011, at 3:13 AM, Dirk Schulze wrote: >>> I'd like to know what the actual threat of such timing attacks are. I've >>> seen claims of a maximum theoretical leak rate (in bits/s) but then counter >>> claims that since, in this case, it would be hard to distinguish the >>> difference in slowdown between CSS shaders and general page rendering, that >>> the real rate is much lower. And, at least in the case of Safari, you can't >>> always be sure that getting a rAF callback means you're about to draw. >>> >>> Does anyone have hard data on this? >> >> At a minimum, please do not land an implementation for this feature >> without a way for ports that are concerned about this security feature >> to disable it independently of both CSS_FILTERS and WEBGL. Contrary >> to your previous assertion, the security implications are quite >> different than those with WebGL. Sorry, I was assuming a WebGL that allowed input from canvasContext.drawElement. At that point I think they are close enough to call the same (no doubt I'm wrong! :) Even without drawElement, WebGL offers a lot of attack vectors. > We already discussed the HW acceleration of SVG Filters on > https://bugs.webkit.org/show_bug.cgi?id=70099 and the implementation of CSS > Filters earlier on this mailing list. We agreed that we will continue to use > the implemented software rendering as fallback for Filters. CSS Shaders won't > be included. Shaders should just be supported if HW acceleration is enabled. > And I think as a minimum consensus on bug 70099 most people on the thread > agreed to go on with GraphicsContext3D for now. In my opinion it means we > would have the same security concerns like on WebGL. That's also one reason > why I think that the WEBGL flag would match these needs quite well, even if > CSS Shaders rely just indirectly to WebGL. If the flag is not enabled, CSS > Shaders are deactivated (and ignored if web developers use them in their > filter chain) and Filters take the software rendering fallback. Adam's point in the bug is that any operation that can access colour channels might be able to perform a timing attack. This would include SVG filters operating on HTML content without any hardware acceleration. For this reason I'm still tempted to suggest the combination of CSS_FILTERS + WEBGL is enough of a switch for ports to disable this, but I'm happy to add another one. I'm not sure at what point we should take the discussion from this list and onto bugzilla. Dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Security problems with CSS shaders (was Re: Starting implementation on W3C Filter Effects)
Am 24.10.2011 um 21:51 schrieb Adam Barth: >> >> I'd like to know what the actual threat of such timing attacks are. I've >> seen claims of a maximum theoretical leak rate (in bits/s) but then counter >> claims that since, in this case, it would be hard to distinguish the >> difference in slowdown between CSS shaders and general page rendering, that >> the real rate is much lower. And, at least in the case of Safari, you can't >> always be sure that getting a rAF callback means you're about to draw. >> >> Does anyone have hard data on this? > > At a minimum, please do not land an implementation for this feature > without a way for ports that are concerned about this security feature > to disable it independently of both CSS_FILTERS and WEBGL. Contrary > to your previous assertion, the security implications are quite > different than those with WebGL. We already discussed the HW acceleration of SVG Filters on https://bugs.webkit.org/show_bug.cgi?id=70099 and the implementation of CSS Filters earlier on this mailing list. We agreed that we will continue to use the implemented software rendering as fallback for Filters. CSS Shaders won't be included. Shaders should just be supported if HW acceleration is enabled. And I think as a minimum consensus on bug 70099 most people on the thread agreed to go on with GraphicsContext3D for now. In my opinion it means we would have the same security concerns like on WebGL. That's also one reason why I think that the WEBGL flag would match these needs quite well, even if CSS Shaders rely just indirectly to WebGL. If the flag is not enabled, CSS Shaders are deactivated (and ignored if web developers use them in their filter chain) and Filters take the software rendering fallback. Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Security problems with CSS shaders (was Re: Starting implementation on W3C Filter Effects)
On Mon, Oct 24, 2011 at 9:38 PM, Dean Jackson wrote: > On 24/10/2011, at 9:08 PM, Adam Barth wrote: >> How have you solved the security problems with CSS Shaders? >> Specifically, timing attacks can be used to extract image information >> passed to shaders and many things WebKit renders are sensitive and >> should not be exposed to the web site (e.g., the color of visited >> links). > > This is a good question and I know that I don't have the answers (and can't > even claim to understand all the implications). > > I think the most important restriction is that shaders should not apply > cross-origin. e.g. iframes and probably anything with children from > another domain (unless it is marked as ok via CORS). There's an issue even with same-origin content. The issues are quite similar to the security issues with canvas.drawElement. Please see the extensive discussion on https://bugs.webkit.org/show_bug.cgi?id=69044. > The possibility of leaking information such as visited links, or maybe > reconstructing text which could be fed to OCR, is more difficult. Is this > really specific to CSS Shaders? SVG filters would theoretically be able to do > the same thing. In fact, given enough knowledge of WebKit rendering one could > imagine tweaking the style of an element in a way that causes a measurable > rendering slowdown. If that were true, it would be a serious privacy attack. We've taken care that a web site cannot learn about which links the user has visited, even with tricky timing attacks. For example, visited and non-visited links cannot have styles that differ in the alpha channel because differences in the alpha channel show up as differences in rendering time. > I'd like to know what the actual threat of such timing attacks are. I've seen > claims of a maximum theoretical leak rate (in bits/s) but then counter claims > that since, in this case, it would be hard to distinguish the difference in > slowdown between CSS shaders and general page rendering, that the real rate > is much lower. And, at least in the case of Safari, you can't always be sure > that getting a rAF callback means you're about to draw. > > Does anyone have hard data on this? At a minimum, please do not land an implementation for this feature without a way for ports that are concerned about this security feature to disable it independently of both CSS_FILTERS and WEBGL. Contrary to your previous assertion, the security implications are quite different than those with WebGL. 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. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Security problems with CSS shaders (was Re: Starting implementation on W3C Filter Effects)
On 24/10/2011, at 9:08 PM, Adam Barth wrote: > How have you solved the security problems with CSS Shaders? > Specifically, timing attacks can be used to extract image information > passed to shaders and many things WebKit renders are sensitive and > should not be exposed to the web site (e.g., the color of visited > links). This is a good question and I know that I don't have the answers (and can't even claim to understand all the implications). I think the most important restriction is that shaders should not apply cross-origin. e.g. iframes and probably anything with children from another domain (unless it is marked as ok via CORS). The possibility of leaking information such as visited links, or maybe reconstructing text which could be fed to OCR, is more difficult. Is this really specific to CSS Shaders? SVG filters would theoretically be able to do the same thing. In fact, given enough knowledge of WebKit rendering one could imagine tweaking the style of an element in a way that causes a measurable rendering slowdown. I'd like to know what the actual threat of such timing attacks are. I've seen claims of a maximum theoretical leak rate (in bits/s) but then counter claims that since, in this case, it would be hard to distinguish the difference in slowdown between CSS shaders and general page rendering, that the real rate is much lower. And, at least in the case of Safari, you can't always be sure that getting a rAF callback means you're about to draw. Does anyone have hard data on this? Dean ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Security problems with CSS shaders (was Re: Starting implementation on W3C Filter Effects)
On Mon, Oct 24, 2011 at 9:02 PM, Dean Jackson wrote: > On 22/09/2011, at 11:30 AM, Dean Jackson wrote: >> Dirk (known in these parts as krit) reminded me that I had not emailed >> webkit-dev about the plans to start an implementation of W3C's new Filter >> Effects specification. >> >> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html >> >> The quick summary is that this exposes the 'filter' property from SVG to >> everything in CSS, and adds some shorthands for common effects so people >> don't have to write XML in order to do something like a blur or sepia >> effect. The spec has received a fair amount of input from the CSS and SVG >> working groups, and particularly from Apple, Google, Mozilla, Opera and >> Adobe. > > A followup: we're going to start work on the CSS Shaders proposal [1] soon. > Adobe have published their implementation which was specific to Chromium, and > we'll be working with them to split it into small patches that can land in > the coming weeks. A good introduction to the technology is [2]. > > This will be done behind the ENABLE_CSS_FILTERS macro, but also with the > guards for ENABLE_WEBGL since the implementation (and security) requirements > are so similar. How have you solved the security problems with CSS Shaders? Specifically, timing attacks can be used to extract image information passed to shaders and many things WebKit renders are sensitive and should not be exposed to the web site (e.g., the color of visited links). Adam > [1] https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html > [2] www.adobe.com/devnet/html5/articles/css-shaders.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
