New issue
Advanced search Search tips
Starred by 4 users
Status: Fixed
Owner:
Closed: Jul 14
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux, Windows, Chrome, Mac
Pri: 2
Type: Bug-Security



Sign in to add a comment
Security: Cross-origin pixel reading and history sniffing via SVG filter timing attack
Reported by dkohl...@eng.ucsd.edu, Jan 27 2017 Back to list
VULNERABILITY DETAILS
By rendering a FeConvolveMatrix SVG filter over a target iframe and timing its execution an attacking page can extract pixel values from a cross-origin page being iframe'd.

This also allows reading ones own origin for history sniffing.

This is based on previous work we did, see http://cseweb.ucsd.edu/~dkohlbre/papers/subnormal.pdf

VERSION
Chrome Version: at least 54 to 57.02987.8
Operating System: Ubuntu Linux 16.10, Windows 10, OSX 10.11.6, ChromeOS 55.0.2883.105.

REPRODUCTION CASE
I've attached a PoC that reconstructs a 48x48 px region from the chosen origin into a canvas.
It works very well on static pages, and will work intermittently on active pages.

Up the pixel multiplier if it doesn't seem to be working on your machine. (100-500 are reasonable ranges, and it depends on your build and env what works best)

screenshot of a successful run is also attached.

NOTES
This must be run on a Chrome platform that supports GPU acceleration of SVG filters. (Ex: Mac mini isn't vulnerable)
The attack does not run on the GPU, but takes advantage of the FTZ and DAZ FPU flags being disabled if the element being rendered is already texture backed.

This bug will be included in a USENIX Security conference submission (2/16/17) but will not be published for at least several months after that.

DETAILS
Normally it appears that Skia sets the FPU DAZ and FTZ flags when executing SVG filters on the CPU. However, if the element being rendered is already in the GPU pipeline (forced with transform:rotateY(1deg)) then these flags are not set. We are taking advantage of floating point multiply timing differences on the CPU, which we get back to via making a kernel of size >36. see https://cs.chromium.org/chromium/src/third_party/skia/src/effects/SkMatrixConvolutionImageFilter.cpp?l=304

We are using timing differences in floating point multiplies between 0*subnormal and 2.x*subnormal. See https://cs.chromium.org/chromium/src/third_party/skia/src/effects/SkMatrixConvolutionImageFilter.cpp?l=186 etc.

It is highly likely that other SVG filters are impacted by this bug in the same way. As long as you can cause a bail from the GPU so that the FTZ and DAZ flags aren't set any multiply with secret data is vulnerable. Division is vulnerable even with FTZ and DAZ.
 
chrome_convolve.html
4.4 KB View Download
chrome_pxbench_exp.js
7.9 KB View Download
Comment 1 by est...@chromium.org, Jan 27 2017
Components: Blink>SVG Privacy
Labels: Security_Severity-Low Security_Impact-Stable OS-Chrome OS-Linux OS-Mac OS-Windows
Owner: senorblanco@chromium.org
Status: Assigned
senorblanco, could you please take a look at this? Looks similar to other reports you've handled in the past ( issue 615851 ,  issue 586820 ). Thanks.
example_result.png
108 KB View Download
Project Member Comment 3 by sheriffbot@chromium.org, Jan 28 2017
Labels: Pri-2
Cc: fs...@chromium.org
Note to self: this will probably require a fix similar to https://crrev.com/014a9a0ea7260b37773adb545b7cabbff80423b9 in that we'll enable flush-to-zero for denorms, but before going into the GPU path as well as the CPU path.
As an additional note, even with FTZ/DAZ set any sqrt over secret data is timing vulnerable for single precision floats. I didn't see any of these when I looked through the filters.

For double precision (Skia looks like its all/mostly single precision) both div and sqrt are vulnerable even with FTZ/DAZ.
Comment 6 by palmer@chromium.org, Feb 24 2017
Cc: palmer@chromium.org jsc...@chromium.org
jschuh and I were talking about this, and thought that there could be some CORS-based defense to this — the target site would have to opt in to cross-site SVG filtering before Chrome would let the attacking site run a filter. Is something like that possible?
Hi,
We are going to be pushing out the final version of our paper (which includes a technical discussion of this bug) on Thursday (June 29th).
We can get the paper held back until the conference (Aug 16th), or we can omit some technical detail (ex: omit the name of the vulnerable filter) if there will be a patch available between now and August.
Let me know what the needed restrictions are.
Cc: -fs...@chromium.org senorblanco@chromium.org
Owner: fs...@chromium.org
Status: Started
#7: Thank you for being nice. :) You can go ahead and disclose. fserb has a patch up for review now, and we think we can get it merged into 60 and maybe even 59. This bug will get updated when that lands, so you'll know. Thanks!
Cc: enne@chromium.org
Project Member Comment 11 by bugdroid1@chromium.org, Jun 28
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/98168e6a9dbd0c52982e47e68baafeda3d8c0192

commit 98168e6a9dbd0c52982e47e68baafeda3d8c0192
Author: Fernando Serboncini <fserb@chromium.org>
Date: Wed Jun 28 20:30:33 2017

Disable subnormal floats on GL renderer filters and bg filters

This prevents timing attacks using SVG filters

Bug:  686253 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I54534bf93c4dfe954f667e5c210aa83d5c9abcf4
Reviewed-on: https://chromium-review.googlesource.com/552957
Commit-Queue: Fernando Serboncini <fserb@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#483116}
[modify] https://crrev.com/98168e6a9dbd0c52982e47e68baafeda3d8c0192/cc/output/gl_renderer.cc

fserb: Thanks again. :) Assuming that the PoC indeed does not work with your patch applied, you can go ahead and all allpublic to the labels when you mark this Fixed.

Also, what about Android and Fuchsia platforms? Any reason the attack would not have worked on those platforms?
Btw, please let us know when the paper is out (and share it ;), so I can open the bug.
Labels: Merge-Request-60 allpublic Merge-Request-59
Status: Fixed
Project Member Comment 15 by sheriffbot@chromium.org, Jun 30
Labels: -Merge-Request-60 Hotlist-Merge-Review Merge-Review-60
This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Restrict-View-SecurityTeam
Labels: -Merge-Review-60 Merge-Approved-60
This bug meets the bar for merge to M60. Approving merge. (branch: 3112)
Labels: -Merge-Request-59 Merge-Rejected-59
Rejecting merge to M59. We've already rolled out to 100%. Please confirm if this bug is  critical enough to warrant a respin. However, reading the description and seeing this is a low priority bug, it doesn't appear to be. 
Project Member Comment 19 by bugdroid1@chromium.org, Jul 4
Labels: -merge-approved-60 merge-merged-3112
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a696ef7e95f81c321475c4a5171093df979ca31d

commit a696ef7e95f81c321475c4a5171093df979ca31d
Author: Fernando Serboncini <fserb@chromium.org>
Date: Tue Jul 04 14:24:30 2017

Disable subnormal floats on GL renderer filters and bg filters

This prevents timing attacks using SVG filters

TBR=fserb@chromium.org

(cherry picked from commit 98168e6a9dbd0c52982e47e68baafeda3d8c0192)

Bug:  686253 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I54534bf93c4dfe954f667e5c210aa83d5c9abcf4
Reviewed-on: https://chromium-review.googlesource.com/552957
Commit-Queue: Fernando Serboncini <fserb@chromium.org>
Reviewed-by: enne <enne@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#483116}
Reviewed-on: https://chromium-review.googlesource.com/558676
Reviewed-by: Fernando Serboncini <fserb@chromium.org>
Cr-Commit-Position: refs/branch-heads/3112@{#511}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/a696ef7e95f81c321475c4a5171093df979ca31d/cc/output/gl_renderer.cc

Cc: pnangunoori@chromium.org
Labels: Needs-Feedback
Tested the issue on Mac OS 10.12.5, Ubuntu 14.04 and Windows 10 using Chrome Beta version M60 - 60.0.3112.66 as per the issue mentioned in original comment. Observed that test doesn’t initiate in the Windows and Ubuntu machines and an alert “Uncaught ReferenceError: init is not defined” is seen in the console after clicking on "RUN" button. However in Mac, test is completed.

@fserb -- Could you please let us know whether the behavior noticed on Mac is intended or not. It would help us in further testing the issue. Please refer the screenshots attached.

Please let us know if we have missed anything.

Thanks in advance.

686253.png
572 KB View Download
686253-MAC.png
248 KB View Download
Labels: -Needs-Feedback
I don't know about the init thing (it was running fine on my Ubuntu) last I tried. It seems you are missing a file, did you download the JS file and it's on the same directory?

But the Mac output you are seeing means it didn't work (the Reconstruction image doesn't contain any information related to the Reference image). I.e., the fix fixed it.


Labels: M-61
Below are the accuracy levels that i'm noticing for Latest Beta#60.0.3112.66.

Win7: [80.25]
Mac 10.12.5: [50.04]
Linux Ubuntu 14.04: [49.95]

Thank you!
Re: #12: Should this bug be marked as affecting Android and/or Fuchsia also?
Can you send a screenshot of the win7 one? I wanna see what 80% looks like.
OK, seems like i was switching focus from SVG testing tab earlier, that might be the reason it was showing different accuracy? Now i'm seeing <50 on the same Win7 machine.
Accuracy_Win7.JPG
108 KB View Download
Status: Started
hmm. This is weird.
Comment 28 Deleted
Hi,
To be clear (and I should've put this on the PoC itself!) any % accuracy not near 50% is bad.

If the recovered image looks like the input image, or even an inverted copy as in that Win7 example, then the attack still works.

Interestingly, that test is showing that for that configuration the timing deltas are backwards, but still exists.
Yeah. I got that. Reopening on win7 to see what's up.
I just got 61.6% on Win10 with 61.0.3141.7 so I think this may affect all windows.
Here is the attached accuracy for Canary#61.0.3156.0 on Win7 w/ switching tab focus.
Canary_Win7.JPG
89.6 KB View Download
It looks like MSC doesn't define __SSE__ which is what we use to know if we can use _mm_set_csr(). We assume SSE2 as a min-spec in Chrome, so maybe this should be:

#if defined(ARCH_CPU_X86_FAMILY)
Fix on the way.
Re:#24: When dealing with an earlier timing attack, I wrote an ARM version of 
the subnormal-float-disabler, but it did not fix the issue -- I couldn't 
figure out why. However, in the meantime, a patch landed to enable main-frame
before-activation in CC, which scrambled the timing enough to foil the
exploit.
I take that back. :)

Project Member Comment 37 by bugdroid1@chromium.org, Jul 13
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a9563a849fc62ce0be68cb60fe740d48eff397a3

commit a9563a849fc62ce0be68cb60fe740d48eff397a3
Author: Fernando Serboncini <fserb@chromium.org>
Date: Thu Jul 13 23:05:37 2017

Use ARCH_CPU_X86_FAMILY instead of SSE, for subnormal float disabler

MSC doesn't define SSE, so this wasn't working properly on Windows

Bug:  686253 
Change-Id: I5e49e9dec43228288261160d8e9eede9b4a6bf75
Reviewed-on: https://chromium-review.googlesource.com/570351
Commit-Queue: Fernando Serboncini <fserb@chromium.org>
Reviewed-by: Vladimir Levin <vmpstr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#486517}
[modify] https://crrev.com/a9563a849fc62ce0be68cb60fe740d48eff397a3/cc/base/math_util.cc
[modify] https://crrev.com/a9563a849fc62ce0be68cb60fe740d48eff397a3/cc/base/math_util.h

Project Member Comment 38 by sheriffbot@chromium.org, Jul 14
Status: Fixed
Please mark security bugs as fixed as soon as the fix lands, and before requesting merges. This update is based on the merge- labels applied to this issue. Please reopen if this update was incorrect.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: Merge-Request-60
Requesting a second merge on 60, because it wasn't working properly on Windows.
Project Member Comment 40 by sheriffbot@chromium.org, Jul 14
Labels: -Merge-Request-60 Merge-Review-60
This bug requires manual review: We are only 10 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
The previous one was approved. This one is even simpler. It's replacing a #ifdef from __SSE__ to X86_ARCH so the code that used to run on mac/linux also gets triggered on windows. But it's literally 2 instructions. :)

Cc: bustamante@chromium.org
bustamante@ for M60-Merge-Review.
Labels: -Merge-Review-60 Merge-Approved-60
Cc: brajkumar@chromium.org
Labels: Needs-Feedback
Tested this issue on Ubuntu 14.04 and Windows-10 using chrome latest dev #61.0.3159.5 and observed the pixel rendering in different accuracy's. 

Attaching screen shot for reference, Could anyone please take a look on it and let us know if the fix is working as intended or not for M61? 

Thanks!
Linux.png
215 KB View Download
Windows (1).PNG
392 KB View Download
Yes, that looks "good" (as in, the results looks nothing like the reference, so nothing was sniffed -- doesn't matter that the different platforms give different results, just that they don't resemble the reference).
Project Member Comment 46 by bugdroid1@chromium.org, Jul 18
Labels: -merge-approved-60
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0bc594ca693eb677b9ba658ee939eaa9abbf35c5

commit 0bc594ca693eb677b9ba658ee939eaa9abbf35c5
Author: Fernando Serboncini <fserb@chromium.org>
Date: Tue Jul 18 14:15:24 2017

Use ARCH_CPU_X86_FAMILY instead of SSE, for subnormal float disabler

MSC doesn't define SSE, so this wasn't working properly on Windows

TBR=fserb@chromium.org

(cherry picked from commit a9563a849fc62ce0be68cb60fe740d48eff397a3)

Bug:  686253 
Change-Id: I5e49e9dec43228288261160d8e9eede9b4a6bf75
Reviewed-on: https://chromium-review.googlesource.com/570351
Commit-Queue: Fernando Serboncini <fserb@chromium.org>
Reviewed-by: Vladimir Levin <vmpstr@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#486517}
Reviewed-on: https://chromium-review.googlesource.com/574741
Reviewed-by: Fernando Serboncini <fserb@chromium.org>
Cr-Commit-Position: refs/branch-heads/3112@{#632}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/0bc594ca693eb677b9ba658ee939eaa9abbf35c5/cc/base/math_util.cc
[modify] https://crrev.com/0bc594ca693eb677b9ba658ee939eaa9abbf35c5/cc/base/math_util.h

Tested this issue on Windows-7,Mac 10.12.5 and Ubuntu 14.04 using chrome latest Beta #60.0.3112.72 and observed the pixel rendering in different accuracy's. 

Attaching screen shots for reference, Could anyone please take a look on it and let us know if the fix is working as intended or not for M60? 

Thank You!
686253(Mac).png
235 KB View Download
686253(Windows).PNG
172 KB View Download
LGTM
Please find the Linux screen shot for reference.
686253(Linux).png
217 KB View Download
Also LGTM
Labels: M-60
Labels: Release-0-M60
Labels: CVE-2017-5107
Sign in to add a comment