3.53 KB, text/html
3.58 KB, text/html
1.05 KB, patch
|Details | Diff | Splinter Review|
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.)
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
Keywords: csectype-sop, sec-high
(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)
(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.
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
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+
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.
status-firefox51: --- → wontfix
status-firefox52: --- → affected
status-firefox53: --- → affected
status-firefox54: --- → affected
status-firefox-esr45: --- → affected
status-firefox-esr52: --- → affected
tracking-firefox52: --- → +
tracking-firefox53: --- → +
tracking-firefox54: --- → +
tracking-firefox-esr45: --- → 52+
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox54: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Comment on attachment 8835640 [details] [diff] [review] treat subnormals as zero Fix a sec-high. Aurora53+ & ESR45+.
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+
status-firefox53: affected → fixed
status-firefox52: affected → fixed
status-firefox-esr45: affected → fixed
tracking-firefox-esr52: --- → ?
status-firefox-esr52: affected → fixed
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!
Status: RESOLVED → VERIFIED
status-firefox52: fixed → verified
status-firefox53: fixed → verified
status-firefox54: fixed → verified
status-firefox-esr45: fixed → verified
status-firefox-esr52: fixed → verified
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.