Re: [webkit-dev] Timing attacks on CSS Shaders (was Re:Security problems with CSS shaders)
On Fri, Dec 9, 2011 at 2:40 PM, Vincent Hardy vha...@adobe.com wrote: On Dec 7, 2011, at 7:29 PM, Adam Barth wrote: On Wed, Dec 7, 2011 at 7:23 PM, Vincent Hardy vha...@adobe.com wrote: @chris So I take back my statement that CSS Shaders are less dangerous than WebGL. They are more!!! It seems to me that the differences are: a. It is easier to do the timing portion of a timing attack in WebGL because it all happens in a script and the timing is precise. With CSS shaders, the timing is pretty coarse. b. The content that a CSS shader has access to may be more sensitive than the content a WebGL shader has access to because currently, WebGL cannot render HTML (but isn't it possible to render an SVG with a foreignObject containing HTML into a 2D canvas, and then use that as a texture? In that case, wouldn't the risk be the same? Or is the canvas tainted in that case and cannot be used as a texture?). Bear in mind that these security problems have been addressed in WebGL. WebGL no long suffers from these vulnerabilities. Yes, I understand WebGL now assumes CORS for allowing/disallowing access to resources. But my point was to clarify what is possible in terms of timing and what is possible (or may become possible) in terms of rendering. Timing on CSS shaders is coarse (because there is not precise way to time how long rendering of the shader takes unlike in WebGL). The attacker would rely on requestAnimationFrame, and the time that is measured with that method includes other processing than just the shader. So the timing measure is rough. It is definitely important that we protect against the threat, but my point is that the time measure is not great. @charles Can this proposal be moved forward on CORS + HTMLMediaElement, HTMLImageElement and HTMLCanvasElement? At the last FX meeting, I got an action to sync. up with the CORS group and discuss how CORS would apply to CSS shaders. It's very unclear to me how CORS can help in this situation. Can you explain what you have in mind? When a shader that applies to an element comes from a different origin than the rendered content, then rendering of the element would be blanked. The shader origin would be the shader's own url, the url of the page it is embedded in or the url of the script that created it dynamically (e.g., by injecting one dynamically with data: url for example, something Dean just mentioned to me in a conversation we had). If there is any mismatch between the origin of the shader and the origin of the shaded content, then the rendering would be blanked (unless CORS on the shaded content gives permission to the shader's origin). This would be done recursively on the content. It is unclear to me if any mismatch should blank out the whole rendering or if only the nodes in the tree that do not match should be blanked. As discussed previously, this approach is insufficient because some sensitive data is unrelated to cross-origin resources. For example, the color of hyperlinks is sensitive data but is unrelated to cross-origin resources, as is information displayed by the file upload control. The action item is to discuss this with the WebApps group. I agree that either the WebApps working group or the FX task force is the best place to discuss this topic. I've already started a thread on the FX task force mailing list, if you'd like to continue the discussion there. If you prefer the WebApps working group, please feel free to start a thread on public-webapps. Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Timing attacks on CSS Shaders (was Re:Security problems with CSS shaders)
From: Adam Barth aba...@webkit.orgmailto:aba...@webkit.org Date: Sat, 10 Dec 2011 00:34:42 -0800 To: Adobe Systems vha...@adobe.commailto:vha...@adobe.com Cc: webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Timing attacks on CSS Shaders (was Re:Security problems with CSS shaders) On Fri, Dec 9, 2011 at 2:40 PM, Vincent Hardy vha...@adobe.commailto:vha...@adobe.com wrote: On Dec 7, 2011, at 7:29 PM, Adam Barth wrote: On Wed, Dec 7, 2011 at 7:23 PM, Vincent Hardy vha...@adobe.commailto:vha...@adobe.com wrote: @chris So I take back my statement that CSS Shaders are less dangerous than WebGL. They are more!!! It seems to me that the differences are: a. It is easier to do the timing portion of a timing attack in WebGL because it all happens in a script and the timing is precise. With CSS shaders, the timing is pretty coarse. b. The content that a CSS shader has access to may be more sensitive than the content a WebGL shader has access to because currently, WebGL cannot render HTML (but isn't it possible to render an SVG with a foreignObject containing HTML into a 2D canvas, and then use that as a texture? In that case, wouldn't the risk be the same? Or is the canvas tainted in that case and cannot be used as a texture?). Bear in mind that these security problems have been addressed in WebGL. WebGL no long suffers from these vulnerabilities. Yes, I understand WebGL now assumes CORS for allowing/disallowing access to resources. But my point was to clarify what is possible in terms of timing and what is possible (or may become possible) in terms of rendering. Timing on CSS shaders is coarse (because there is not precise way to time how long rendering of the shader takes unlike in WebGL). The attacker would rely on requestAnimationFrame, and the time that is measured with that method includes other processing than just the shader. So the timing measure is rough. It is definitely important that we protect against the threat, but my point is that the time measure is not great. @charles Can this proposal be moved forward on CORS + HTMLMediaElement, HTMLImageElement and HTMLCanvasElement? At the last FX meeting, I got an action to sync. up with the CORS group and discuss how CORS would apply to CSS shaders. It's very unclear to me how CORS can help in this situation. Can you explain what you have in mind? When a shader that applies to an element comes from a different origin than the rendered content, then rendering of the element would be blanked. The shader origin would be the shader's own url, the url of the page it is embedded in or the url of the script that created it dynamically (e.g., by injecting one dynamically with data: url for example, something Dean just mentioned to me in a conversation we had). If there is any mismatch between the origin of the shader and the origin of the shaded content, then the rendering would be blanked (unless CORS on the shaded content gives permission to the shader's origin). This would be done recursively on the content. It is unclear to me if any mismatch should blank out the whole rendering or if only the nodes in the tree that do not match should be blanked. As discussed previously, this approach is insufficient because some sensitive data is unrelated to cross-origin resources. For example, the color of hyperlinks is sensitive data but is unrelated to cross-origin resources, as is information displayed by the file upload control. Yes, I agree it is insufficient. But I think we agree that CORS is part of the solution. My understanding is that the defense could be built by mixing multiple protections. I think CORS can address the issue of getting access to pixels from a different domain, which is one of the problems we are trying to solve. The other issues you have raised, I think are generic to any solution (not just CSS shaders) where we might want to give access to the rendered HTML output (e.g., render an element or an HTML file in a canvas, for example). They also need to be addressed. The action item is to discuss this with the WebApps group. I agree that either the WebApps working group or the FX task force is the best place to discuss this topic. I've already started a thread on the FX task force mailing list, if you'd like to continue the discussion there. If you prefer the WebApps working group, please feel free to start a thread on public-webapps. Yes, I'll continue the discussion on public-fx. Dean is also preparing a summary of the issues which I think he will send there. Thanks, Vincent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Timing attacks on CSS Shaders (was Re:Security problems with CSS shaders)
On Dec 7, 2011, at 7:29 PM, Adam Barth wrote: On Wed, Dec 7, 2011 at 7:23 PM, Vincent Hardy vha...@adobe.com wrote: @chris So I take back my statement that CSS Shaders are less dangerous than WebGL. They are more!!! It seems to me that the differences are: a. It is easier to do the timing portion of a timing attack in WebGL because it all happens in a script and the timing is precise. With CSS shaders, the timing is pretty coarse. b. The content that a CSS shader has access to may be more sensitive than the content a WebGL shader has access to because currently, WebGL cannot render HTML (but isn't it possible to render an SVG with a foreignObject containing HTML into a 2D canvas, and then use that as a texture? In that case, wouldn't the risk be the same? Or is the canvas tainted in that case and cannot be used as a texture?). Bear in mind that these security problems have been addressed in WebGL. WebGL no long suffers from these vulnerabilities. Yes, I understand WebGL now assumes CORS for allowing/disallowing access to resources. But my point was to clarify what is possible in terms of timing and what is possible (or may become possible) in terms of rendering. Timing on CSS shaders is coarse (because there is not precise way to time how long rendering of the shader takes unlike in WebGL). The attacker would rely on requestAnimationFrame, and the time that is measured with that method includes other processing than just the shader. So the timing measure is rough. It is definitely important that we protect against the threat, but my point is that the time measure is not great. @charles Can this proposal be moved forward on CORS + HTMLMediaElement, HTMLImageElement and HTMLCanvasElement? At the last FX meeting, I got an action to sync. up with the CORS group and discuss how CORS would apply to CSS shaders. It's very unclear to me how CORS can help in this situation. Can you explain what you have in mind? When a shader that applies to an element comes from a different origin than the rendered content, then rendering of the element would be blanked. The shader origin would be the shader's own url, the url of the page it is embedded in or the url of the script that created it dynamically (e.g., by injecting one dynamically with data: url for example, something Dean just mentioned to me in a conversation we had). If there is any mismatch between the origin of the shader and the origin of the shaded content, then the rendering would be blanked (unless CORS on the shaded content gives permission to the shader's origin). This would be done recursively on the content. It is unclear to me if any mismatch should blank out the whole rendering or if only the nodes in the tree that do not match should be blanked. The action item is to discuss this with the WebApps group. Kind regards, Vincent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Timing attacks on CSS Shaders (was Re:Security problems with CSS shaders)
Hi Nat, I wont argue on how precise or not the timing channel is because I think, as I was saying below, that we need to protect against the threat no matter what. Cheers, Vincent. From: Nat Duca nd...@google.commailto:nd...@google.com Date: Fri, 9 Dec 2011 16:30:50 -0800 To: Adobe Systems vha...@adobe.commailto:vha...@adobe.com Cc: Adam Barth aba...@webkit.orgmailto:aba...@webkit.org, webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Timing attacks on CSS Shaders (was Re:Security problems with CSS shaders) I do not think its safe to assume that timing of CSS shaders is coarse. webkitRequestAnimationFrame tells you when the browser draws. If you start with something that takes exactly 16ms to composite, then everything you add to it from there is timing.. On Fri, Dec 9, 2011 at 2:40 PM, Vincent Hardy vha...@adobe.commailto:vha...@adobe.com wrote: On Dec 7, 2011, at 7:29 PM, Adam Barth wrote: On Wed, Dec 7, 2011 at 7:23 PM, Vincent Hardy vha...@adobe.commailto:vha...@adobe.com wrote: @chris So I take back my statement that CSS Shaders are less dangerous than WebGL. They are more!!! It seems to me that the differences are: a. It is easier to do the timing portion of a timing attack in WebGL because it all happens in a script and the timing is precise. With CSS shaders, the timing is pretty coarse. b. The content that a CSS shader has access to may be more sensitive than the content a WebGL shader has access to because currently, WebGL cannot render HTML (but isn't it possible to render an SVG with a foreignObject containing HTML into a 2D canvas, and then use that as a texture? In that case, wouldn't the risk be the same? Or is the canvas tainted in that case and cannot be used as a texture?). Bear in mind that these security problems have been addressed in WebGL. WebGL no long suffers from these vulnerabilities. Yes, I understand WebGL now assumes CORS for allowing/disallowing access to resources. But my point was to clarify what is possible in terms of timing and what is possible (or may become possible) in terms of rendering. Timing on CSS shaders is coarse (because there is not precise way to time how long rendering of the shader takes unlike in WebGL). The attacker would rely on requestAnimationFrame, and the time that is measured with that method includes other processing than just the shader. So the timing measure is rough. It is definitely important that we protect against the threat, but my point is that the time measure is not great. @charles Can this proposal be moved forward on CORS + HTMLMediaElement, HTMLImageElement and HTMLCanvasElement? At the last FX meeting, I got an action to sync. up with the CORS group and discuss how CORS would apply to CSS shaders. It's very unclear to me how CORS can help in this situation. Can you explain what you have in mind? When a shader that applies to an element comes from a different origin than the rendered content, then rendering of the element would be blanked. The shader origin would be the shader's own url, the url of the page it is embedded in or the url of the script that created it dynamically (e.g., by injecting one dynamically with data: url for example, something Dean just mentioned to me in a conversation we had). If there is any mismatch between the origin of the shader and the origin of the shaded content, then the rendering would be blanked (unless CORS on the shaded content gives permission to the shader's origin). This would be done recursively on the content. It is unclear to me if any mismatch should blank out the whole rendering or if only the nodes in the tree that do not match should be blanked. The action item is to discuss this with the WebApps group. Kind regards, Vincent ___ webkit-dev mailing list webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Timing attacks on CSS Shaders (was Re:Security problems with CSS shaders)
On Dec 7, 2011, at 7:23 PM, Vincent Hardy wrote: Hello, @chris So I take back my statement that CSS Shaders are less dangerous than WebGL. They are more!!! It seems to me that the differences are: a. It is easier to do the timing portion of a timing attack in WebGL because it all happens in a script and the timing is precise. With CSS shaders, the timing is pretty coarse. b. The content that a CSS shader has access to may be more sensitive than the content a WebGL shader has access to because currently, WebGL cannot render HTML (but isn't it possible to render an SVG with a foreignObject containing HTML into a 2D canvas, and then use that as a texture? In that case, wouldn't the risk be the same? Or is the canvas tainted in that case and cannot be used as a texture?). Yes, if that were possible (it's not today in WebKit) then WebGL shaders would be even more dangerous because of their more precise timing. - ~Chris cmar...@apple.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Timing attacks on CSS Shaders (was Re:Security problems with CSS shaders)
Hello, @chris So I take back my statement that CSS Shaders are less dangerous than WebGL. They are more!!! It seems to me that the differences are: a. It is easier to do the timing portion of a timing attack in WebGL because it all happens in a script and the timing is precise. With CSS shaders, the timing is pretty coarse. b. The content that a CSS shader has access to may be more sensitive than the content a WebGL shader has access to because currently, WebGL cannot render HTML (but isn't it possible to render an SVG with a foreignObject containing HTML into a 2D canvas, and then use that as a texture? In that case, wouldn't the risk be the same? Or is the canvas tainted in that case and cannot be used as a texture?). @charles Can this proposal be moved forward on CORS + HTMLMediaElement, HTMLImageElement and HTMLCanvasElement? At the last FX meeting, I got an action to sync. up with the CORS group and discuss how CORS would apply to CSS shaders. Cheers, Vincent Date: Mon, 05 Dec 2011 15:59:14 -0800 From: Charles Pritchard ch...@jumis.commailto:ch...@jumis.com To: Chris Marrin cmar...@apple.commailto:cmar...@apple.com Cc: Jonas Sicking jo...@sicking.ccmailto:jo...@sicking.cc, webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Timing attacks on CSS Shaders (was Re: Security problems with CSS shaders) Message-ID: 4edd5ad2.4010...@jumis.commailto:4edd5ad2.4010...@jumis.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 12/5/11 3:34 PM, Chris Marrin wrote: On Dec 5, 2011, at 11:32 AM, Adam Barth wrote: On Mon, Dec 5, 2011 at 10:53 AM, Chris Marrincmar...@apple.commailto:cmar...@apple.com wrote: To be clear, it's not the difference between white and black pixels, it's the difference between pixels with transparency and those without. Can you explain why the attack is limited to distinguishing between black and transparent pixels? My understanding is that these attacks are capable of distinguishing arbitrary pixel values. This is my misunderstanding. I was referring to the attacks using WebGL, which measure the difference between rendering alpha and non-alpha pixels. But I think there is another, more dangerous attack vector specific to CSS shaders. Shaders have the source image (the image of that part of the page) available. So it is an easy thing to make a certain color pixel take a lot longer to render (your 1000x slower case). So you can easily and quickly detect, for instance, the color of a link. Can this proposal be moved forward on CORS + HTMLMediaElement, HTMLImageElement and HTMLCanvasElement? The proposal would really benefit users and authors on those media types, even if it falls short of applying to general HTML elements and CSS urls in the first draft. I realize that it falls short of the lofty goals of the presentation, but it would make a good impact and set the stage for further work. It seems entirely do-able to disable a:visited on elements that have custom filters applied, but, like the timing issues, there needs to be some empirical data on risks before moving forward on them. So I take back my statement that CSS Shaders are less dangerous than WebGL. They are more!!! As I've said many times (with many more expletives), I hate the Internet. I think the solution is clear. We should create a whole new internet where we only let in people we trust. :-) - ~Chris cmar...@apple.commailto:cmar...@apple.com I still love my iPhone. ;-) -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Timing attacks on CSS Shaders (was Re:Security problems with CSS shaders)
On Wed, Dec 7, 2011 at 7:23 PM, Vincent Hardy vha...@adobe.com wrote: @chris So I take back my statement that CSS Shaders are less dangerous than WebGL. They are more!!! It seems to me that the differences are: a. It is easier to do the timing portion of a timing attack in WebGL because it all happens in a script and the timing is precise. With CSS shaders, the timing is pretty coarse. b. The content that a CSS shader has access to may be more sensitive than the content a WebGL shader has access to because currently, WebGL cannot render HTML (but isn't it possible to render an SVG with a foreignObject containing HTML into a 2D canvas, and then use that as a texture? In that case, wouldn't the risk be the same? Or is the canvas tainted in that case and cannot be used as a texture?). Bear in mind that these security problems have been addressed in WebGL. WebGL no long suffers from these vulnerabilities. @charles Can this proposal be moved forward on CORS + HTMLMediaElement, HTMLImageElement and HTMLCanvasElement? At the last FX meeting, I got an action to sync. up with the CORS group and discuss how CORS would apply to CSS shaders. It's very unclear to me how CORS can help in this situation. Can you explain what you have in mind? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
