Bug 1336622 (CVE-2017-5407)

Pixelstealing and history-stealing through floating-point timing side channel with SVG filters.

VERIFIED FIXED in Firefox -esr45

Status

()

defect
VERIFIED FIXED
2 years ago
Last year

People

(Reporter: dkohlbre, Assigned: mstange)

Tracking

({csectype-sop, sec-high})

Trunk
mozilla54
x86_64
All
Points:
---

Firefox Tracking Flags

(firefox-esr4552+ verified, firefox51 wontfix, firefox52+ verified, firefox-esr5252+ verified, firefox53+ verified, firefox54+ verified)

Details

(Whiteboard: [post-critsmash-triage][adv-main52+][adv-esr45.8+][pixel-stealing])

Attachments

(4 attachments, 1 obsolete attachment)

Reporter

Description

2 years ago
Posted file 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.)
Reporter

Comment 1

2 years ago
Posted file PoC part 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?
Status: UNCONFIRMED → NEW
Component: Security → SVG
Ever confirmed: true
Flags: needinfo?(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.
Flags: needinfo?(dholbert) → needinfo?(mstange)
Reporter

Comment 6

2 years ago
(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.
Assignee

Comment 7

2 years ago
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.
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Flags: needinfo?(mstange)
Assignee

Comment 8

2 years ago
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.
Attachment #8835640 - Flags: review?(jmuizelaar)
Comment on attachment 8835640 [details] [diff] [review]
treat subnormals as zero

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

Not great, but butter than nothing.
Attachment #8835640 - Flags: review?(jmuizelaar) → review+
Assignee

Comment 10

2 years ago
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.
Attachment #8835640 - Flags: sec-approval?
sec-approval+ for trunk.
We'll want branches patches (including ESR45) made and nominated as well once this goes in.
Attachment #8835640 - Flags: sec-approval? → sec-approval+
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.
https://hg.mozilla.org/mozilla-central/rev/cd4c3caf3725
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Assignee

Updated

2 years ago
Attachment #8835640 - Flags: approval-mozilla-esr45?
Attachment #8835640 - Flags: approval-mozilla-beta?
Attachment #8835640 - Flags: approval-mozilla-aurora?
Group: core-security → core-security-release
Comment on attachment 8835640 [details] [diff] [review]
treat subnormals as zero

Fix a sec-high. Aurora53+ & ESR45+.
Attachment #8835640 - Flags: approval-mozilla-esr45?
Attachment #8835640 - Flags: approval-mozilla-esr45+
Attachment #8835640 - Flags: approval-mozilla-aurora?
Attachment #8835640 - Flags: approval-mozilla-aurora+
Comment on attachment 8835640 [details] [diff] [review]
treat subnormals as zero

sec-high fix for beta52
Attachment #8835640 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Whiteboard: [post-critsmash-triage]
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main52+][adv-esr45.8+]
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!
Alias: CVE-2017-5407
Group: core-security-release
Whiteboard: [post-critsmash-triage][adv-main52+][adv-esr45.8+] → [post-critsmash-triage][adv-main52+][adv-esr45.8+][pixel-stealing]
You need to log in before you can comment on or make changes to this bug.