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

[Adam Barth]

On Fri, Dec 9, 2011 at 2:40 PM, Vincent Hardy <vhardy at 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 <vhardy at 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