Re: Documenting Timing Attacks in Rendering Engines

Do you think that GLSL could be changed to prevent the timing from
changing depending on the content? Could the GLSL validator be changed
to not allow conditionals dependent on texture samples from the page?

That would eliminate various effects, but at least most shaders
wouldn't do texture indirections anyway, since it's slow on embedded
hardware.

Ralph

On Mon, Dec 12, 2011 at 11:26 AM, Adam Barth <w3c@adambarth.com> wrote:
> Sorry if my previous response came off as abrupt.  Let me try replying
> to your message again.
>
> On Mon, Dec 12, 2011 at 8:38 AM, Vincent Hardy <vhardy@adobe.com> wrote:
>> I think the problem already exists regardless of shaders.
>
> These issues would exist regardless of shaders if we weren't careful
> about maintaining this security property throughout the platform, but
> there's been a bunch of careful work done by many folks over a number
> of years to plug these sorts of leaks.  For example, David Baron
> considered and experimented with timing attacks when he proposed and
> implemented his history sniffing defense, and that's what motivated
> his choices of which CSS properties could differ between visited and
> non-visited links.  Folk have also analyzed other side channels (e.g.,
> http://websec.sv.cmu.edu/visited/visited.pdf), so we have a pretty
> good handle on what is and what is not possible.
>
>> We already have filter effects on SVG content (which may include HTML
>> through foreignObjects). They can impact the rendering time of content. And
>> regardless of shaders / filters, it is possible to modify content and
>> compute the rendering time to detect patterns.
>
> If that's possible, I'd encourage you to report the vulnerability to
> the various vendors (e.g.,
> http://www.chromium.org/Home/chromium-security/reporting-security-bugs)
> in a responsible manner.  These reports will likely qualify for
> rewards via Chromium and Mozilla's vulnerability rewards programs.
>
> Note you'll need to construct a filter effect that has a different
> running time based only on the color of the hyperlink.  Other CSS
> properties are forbidden from varying between visited and non-visited
> hyperlinks.  That's easy to do with a CSS Shader, but it's unclear to
> me how to do that without a shader.
>
>> I'll take a silly and extreme case. If an attacker finds that the rendering
>> of a visited link took a lot more time than rendering a non visited link,
>> he/she could find out, through timing, if a url had been visited by the
>> victim. No shaders involved. May be the attacker just added a very large
>> number of drop shadows to the style of visited links or something else that
>> also impacted rendering.
>
> Yes, that would be a vulnerability.  As far as I know, no one knows
> how to do that without shaders.  We do know how to do this if we could
> apply different effects (such as drop shadows) to visited and
> non-visited hyperlinks, but, as James says, that is forbidden.
>
>> So since we have leakage of information by timing the rendering, I think we
>> need to understand how bad the problem/threat is. As discussed before,
>> shaders and filters may accentuate the issue (because they can slow down
>> rendering of specific colors etc...) but the core issue, I think, is that
>> timing the rendering (in general) leaks information. May be we should find
>> how to obfuscate timing in requestAnimationFrame so that information leakage
>> is reduced/removed. I think Dean has ideas there.
>
> That approach is unlikely to be successful.  Once the information has
> entered the timing channel, it's basically impossible to remove.  You
> can try to hide the information with blocking or noise, but experience
> in many other domains tells us that these mitigations are surprisingly
> easy for attackers to circumvent.
>
> The only approach I'm aware of that has a chance of success is to
> prevent the sensitive information from entering the timing channel in
> the first place.
>
>> I like to think that there are solutions to problems, even though not
>> obvious at first :-). We may apply restrictions where needed. For example, I
>> think CORS addresses some of the issues. Let's try to find out solutions to
>> the other issues.
>>
>> May be I am just an optimist :-)
>
> If you have a specific proposal, I'm happy to review it.  So far I
> haven't seen a proposal that wasn't trivially broken.  Specifically
> for the approach you mention above, relying upon CORS does not address
> the history sniffing risk.
>
> Adam
>

Received on Monday, 12 December 2011 20:01:04 UTC