| 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.
,
Jan 28 2017
,
Feb 1
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.
,
Feb 2
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.
,
Feb 24
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?
,
Jun 28
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.
,
Jun 28
,
Jun 28
#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!
,
Jun 28
,
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
,
Jun 28
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?
,
Jun 30
Btw, please let us know when the paper is out (and share it ;), so I can open the bug.
,
Jun 30
,
Jun 30
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
,
Jun 30
,
Jun 30
This bug meets the bar for merge to M60. Approving merge. (branch: 3112)
,
Jun 30
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.
,
Jul 4
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
,
Jul 12
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.
,
Jul 12
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.
,
Jul 12
,
Jul 12
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!
,
Jul 12
Re: #12: Should this bug be marked as affecting Android and/or Fuchsia also?
,
Jul 13
Can you send a screenshot of the win7 one? I wanna see what 80% looks like.
,
Jul 13
hmm. This is weird.
,
Jul 13
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.
,
Jul 13
Yeah. I got that. Reopening on win7 to see what's up.
,
Jul 13
I just got 61.6% on Win10 with 61.0.3141.7 so I think this may affect all windows.
,
Jul 13
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)
,
Jul 13
Fix on the way.
,
Jul 13
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.
,
Jul 13
I take that back. :)
,
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
,
Jul 14
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
,
Jul 14
Requesting a second merge on 60, because it wasn't working properly on Windows.
,
Jul 14
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
,
Jul 14
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. :)
,
Jul 14
bustamante@ for M60-Merge-Review.
,
Jul 15
,
Jul 18
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!
,
Jul 18
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).
,
Jul 18
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
,
Jul 19
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!
,
Jul 19
LGTM
,
Jul 19
Also LGTM
,
Jul 24
,
Jul 24
,
Jul 25
|
||||||||||||||||||||||||||
| ► Sign in to add a comment | ||||||||||||||||||||||||||
Labels: Security_Severity-Low Security_Impact-Stable OS-Chrome OS-Linux OS-Mac OS-Windows
Owner: senorblanco@chromium.org
Status: Assigned