New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 4 users

Issue metadata

Status: Fixed
Owner:
Closed: Jul 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug-Security



Sign in to add a comment
link

Issue 686253: Security: Cross-origin pixel reading and history sniffing via SVG filter timing attack

Reported by dkohl...@eng.ucsd.edu, Jan 27 2017

Issue description

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 (was: Unconfirmed)
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.

Comment 2 by dkohl...@eng.ucsd.edu, Jan 27 2017

example_result.png
108 KB View Download

Comment 3 by sheriffbot@chromium.org, Jan 28 2017

Project Member
Labels: Pri-2

Comment 4 by senorblanco@chromium.org, Feb 1 2017

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.

Comment 5 by dkohl...@eng.ucsd.edu, Feb 2 2017

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?

Comment 7 by dkohl...@eng.ucsd.edu, Jun 28 2017

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.

Comment 8 by fs...@chromium.org, Jun 28 2017

Cc: -fs...@chromium.org senorblanco@chromium.org
Owner: fs...@chromium.org
Status: Started (was: Assigned)

Comment 9 by palmer@chromium.org, Jun 28 2017

#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!

Comment 10 by fs...@chromium.org, Jun 28 2017

Cc: enne@chromium.org

Comment 11 by bugdroid1@chromium.org, Jun 28 2017

Project Member
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

Comment 12 by palmer@chromium.org, Jun 28 2017

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?

Comment 13 by fs...@chromium.org, Jun 30 2017

Btw, please let us know when the paper is out (and share it ;), so I can open the bug.

Comment 14 by fs...@chromium.org, Jun 30 2017

Labels: Merge-Request-60 allpublic Merge-Request-59
Status: Fixed (was: Started)

Comment 15 by sheriffbot@chromium.org, Jun 30 2017

Project Member
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

Comment 16 by palmer@chromium.org, Jun 30 2017

Labels: -Restrict-View-SecurityTeam

Comment 17 by abdulsyed@chromium.org, Jun 30 2017

Labels: -Merge-Review-60 Merge-Approved-60
This bug meets the bar for merge to M60. Approving merge. (branch: 3112)

Comment 18 by abdulsyed@chromium.org, Jun 30 2017

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.

Comment 19 by bugdroid1@chromium.org, Jul 4 2017

Project Member
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

Comment 20 by pnangunoori@chromium.org, Jul 12 2017

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

Comment 21 by fs...@chromium.org, Jul 12 2017

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.

Comment 22 by manoranj...@chromium.org, Jul 12 2017

Labels: M-61

Comment 23 by manoranj...@chromium.org, Jul 12 2017

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!

Comment 24 by palmer@chromium.org, Jul 12 2017

Re: #12: Should this bug be marked as affecting Android and/or Fuchsia also?

Comment 25 by fs...@chromium.org, Jul 13 2017

Can you send a screenshot of the win7 one? I wanna see what 80% looks like.

Comment 26 by manoranj...@chromium.org, Jul 13 2017

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

Comment 27 by fs...@chromium.org, Jul 13 2017

Status: Started (was: Fixed)
hmm. This is weird.

Comment 28 Deleted

Comment 29 by dkohl...@eng.ucsd.edu, Jul 13 2017

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.

Comment 30 by fs...@chromium.org, Jul 13 2017

Yeah. I got that. Reopening on win7 to see what's up.

Comment 31 by pdr@chromium.org, Jul 13 2017

I just got 61.6% on Win10 with 61.0.3141.7 so I think this may affect all windows.

Comment 32 by manoranj...@chromium.org, Jul 13 2017

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

Comment 33 by senorblanco@chromium.org, Jul 13 2017

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)

Comment 34 by fs...@chromium.org, Jul 13 2017

Fix on the way.

Comment 35 by senorblanco@chromium.org, Jul 13 2017

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.

Comment 36 by fs...@chromium.org, Jul 13 2017

I take that back. :)

Comment 37 by bugdroid1@chromium.org, Jul 13 2017

Project Member
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

Comment 38 by sheriffbot@chromium.org, Jul 14 2017

Project Member
Status: Fixed (was: Started)
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

Comment 39 by fs...@chromium.org, Jul 14 2017

Labels: Merge-Request-60
Requesting a second merge on 60, because it wasn't working properly on Windows.

Comment 40 by sheriffbot@chromium.org, Jul 14 2017

Project Member
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

Comment 41 by fs...@chromium.org, Jul 14 2017

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. :)

Comment 42 by manoranj...@chromium.org, Jul 14 2017

Cc: bustamante@chromium.org
bustamante@ for M60-Merge-Review.

Comment 43 by abdulsyed@chromium.org, Jul 15 2017

Labels: -Merge-Review-60 Merge-Approved-60

Comment 44 by brajkumar@chromium.org, Jul 18 2017

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

Comment 45 by senorblanco@chromium.org, Jul 18 2017

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).

Comment 46 by bugdroid1@chromium.org, Jul 18 2017

Project Member
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

Comment 47 by rbasuvula@chromium.org, Jul 19 2017

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

Comment 48 by senorblanco@chromium.org, Jul 19 2017

LGTM

Comment 49 by rbasuvula@chromium.org, Jul 19 2017

Please find the Linux screen shot for reference.
686253(Linux).png
217 KB View Download

Comment 50 by senorblanco@chromium.org, Jul 19 2017

Also LGTM

Comment 51 by awhalley@chromium.org, Jul 24 2017

Labels: M-60

Comment 52 by awhalley@chromium.org, Jul 24 2017

Labels: Release-0-M60

Comment 53 by awhalley@chromium.org, Jul 25 2017

Labels: CVE-2017-5107

Comment 54 by awhalley@google.com, Jan 2 2018

Labels: reward-topanel

Comment 55 by awhalley@chromium.org, Jan 5 2018

Labels: -reward-topanel reward-unpaid reward-2000
*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
*********************************

Comment 56 by awhalley@google.com, Jan 6 2018

Nice one! The Chrome VRP Panel decided to award $2,000 for this report.

Comment 57 by awhalley@chromium.org, Jan 6 2018

Labels: -reward-unpaid reward-inprocess

Comment 58 by dkohl...@eng.ucsd.edu, Jan 6 2018

Wow! That is great news, thanks! :)

I realized I never responded to #13, sorry about that.
Paper and talk are at https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/kohlbrenner
Tools and PoCs are available at https://cseweb.ucsd.edu/~dkohlbre/floats

Comment 59 by awhalley@chromium.org, Apr 25 2018

Labels: CVE_description-submitted

Sign in to add a comment