1336622 - (CVE-2017-5407) Pixelstealing and history-stealing through floating-point timing side channel with SVG filters.

Status: VERIFIED FIXED

(Core :: SVG, defect)

Description

[David Kohlbrenner]

Attachment: PoC part 1

This is a continuation of https://bugzilla.mozilla.org/show_bug.cgi?id=1131288 that now works on all versions of Firefox.

By rendering SVG filters that don't use the fixed point math implementation over a victim iframe the attacking page can extract pixel information. This leads to SOP violations (reading cross origin visual data) and history sniffing.

I'm attaching a PoC that works on all current versions of Firefox. It uses the feSpecularLighting SVG filter. Specifically, it uses the fact that the alpha channel of the input is multiplied against the surfaceScale property.
By setting the surfaceScale to a subnormal value, we can observe rendering time differences between a black input or a white input. (0*subnormal vs normal*subnormal can have a ~20x difference in speed).

It looks like a number of the filters (feConvolveMatrix, etc) have been ported to a fixed point implementation. This trick is likely to work on more than just the specular lighting filter, but only ones still using fp math.

This attack will be included in a USENIX Security submission (2/16), but even if accepted it won't be public for several months.

(If the PoC is giving you problems, try reloading it and changing the multiplier to something higher. Less than 2000 should still work correctly.)

Comment 1

[David Kohlbrenner]

Attachment: PoC part 2

Comment 2

[Daniel Veditz [:dveditz]]

I can reproduce with the sample black and white checkerboard in the testcase. Had more difficulty with the MDN favicon, but it did pick up the white dino head (everything else was black). I had no luck reading text using data:text/html,<h1>Hi</h1> as the sample.

Chrome runs very fast and generates a random dot pattern. Safari runs slow and generates a random dot pattern.

We could maybe do something with specific transforms, but could we do something systematic like taint the canvas if you're doing transforms on a foreign frame (maybe allow CORS)? Or just disallow transforms on 3rd-party content?

Daniel: who should look at this these days?

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to Daniel Veditz [:dveditz] from comment #2)
> I can reproduce with the sample black and white checkerboard in the
> testcase.

To clarify, did you have to download the testcase files and run them locally? (It looks like "PoC part 1" has 
<script src="pxbench.js">  -- is that meant to be pointed at PoC part 2?)

> Daniel: who should look at this these days?

This sounds like a version of bug 711043.  So perhaps heycam (who worked on that bug) or mstange (who also done some SVG filter work, IIRC) would be good people to look into this.  Tagging mstange to start, since I recall heycam being pretty swamped with stylo stuff right now.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: reporter's testcase, now using Bugzilla-hosted JS (maybe)

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: reporter's testcase (now using Bugzilla-hosted JS and HTTPS-served target)

Comment 6

[David Kohlbrenner]

(In reply to Daniel Veditz [:dveditz] from comment #2)
> I can reproduce with the sample black and white checkerboard in the
> testcase. Had more difficulty with the MDN favicon, but it did pick up the
> white dino head (everything else was black). I had no luck reading text
> using data:text/html,<h1>Hi</h1> as the sample.
> 
> Chrome runs very fast and generates a random dot pattern. Safari runs slow
> and generates a random dot pattern.
> 
> We could maybe do something with specific transforms, but could we do
> something systematic like taint the canvas if you're doing transforms on a
> foreign frame (maybe allow CORS)? Or just disallow transforms on 3rd-party
> content?
> 
> Daniel: who should look at this these days?

We have different versions of this attack for all browsers. But they all break in a similar way. Chrome is currently avoids some versions of this attack by enabling FTZ and DAZ during filter computation. That is safe only for add/sub/mul but not for div or sqrt. (On platforms we've tested at least)

Rendering trickier things than the checkerboard works, but I've not put in the time to tune it to work particularly well.

Comment 7

[Markus Stange [:mstange]]

Nice find.

It looks like the filter code still has a few floating point multiplications and divisions, at http://searchfox.org/mozilla-central/rev/afcf40f3eafd895611a839017730debb58a342a6/gfx/2d/FilterNodeSoftware.cpp#3475-3476,3568,3570

I'm talking to jrmuizel about how to make them fixed point.

Comment 8

[Markus Stange [:mstange]]

Attachment: treat subnormals as zero

A better solution would be to convert all the floating point calculations involved in the lighting filters to fixed point, but this patch fixes the immediate problem and is really safe, so I think we should land and uplift it.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 8835640 [details] [diff] [review]
treat subnormals as zero

Review of attachment 8835640 [details] [diff] [review]:
-----------------------------------------------------------------

Not great, but butter than nothing.

Comment 10

[Markus Stange [:mstange]]

Comment on attachment 8835640 [details] [diff] [review]
treat subnormals as zero

[Security approval request comment]
How easily could an exploit be constructed based on the patch?
Not easily, but it's definitely possible. SVG filter timing attacks are a well-known theoretical attack vector, and the patch points at the surfaceScale field so you'd know where to start looking.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
Somewhat, see above.

Which older supported branches are affected by this flaw?
All of them, this code has been in this state for over three years.

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
This patch should apply cleanly on all affected branches.

How likely is this patch to cause regressions; how much testing does it need?
Extremely low risk of regressions.

Comment 11

[Al Billings [:abillings - ex-MoCo]]

sec-approval+ for trunk.
We'll want branches patches (including ESR45) made and nominated as well once this goes in.

Comment 12

[Daniel Holbert [:dholbert]]

David, thanks for reporting this!

ekr tells me you've been hammering on these timing attacks pretty aggressively.  If you've got more of these sorts of attacks in the pipeline, we're eager to see them & see what we can do about them.

Comment 13

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/cd4c3caf3725

Comment 14

[Gerry Chang [:gchang]]

Comment on attachment 8835640 [details] [diff] [review]
treat subnormals as zero

Fix a sec-high. Aurora53+ & ESR45+.

Comment 15

[Julien Cristau [:jcristau]]

Comment on attachment 8835640 [details] [diff] [review]
treat subnormals as zero

sec-high fix for beta52

Comment 16

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/c005b505ce54

Comment 17

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-beta/rev/7b8aa893944b

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr45/rev/4ba337cdb998

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr52/rev/7b8aa893944b

Comment 20

[Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact [e-mail]]

I reproduced this issue using Fx 51.0.1, on Windows 10 x64.
I can confirm this issue is fixed, I verified Fx 54.0a1, build ID: 20170227030203 and Fx53.0a2, build ID: 20170227004004, Fx52.0b9, build ID: 20170223185858,Fx 45.8.0esr and Fx 52.0esr on Windows 10 x64, Ubuntu 14.04 LTS x64 and Mac OS X 10.11.

Cheers!