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

Issue 675658 link

Starred by 1 user

Issue metadata

Status: Fixed
OOO until 2019-01-24
Closed: Aug 2017
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 1
Type: Bug-Security

Sign in to add a comment

Security: Malicious WebGL page can capture and upload contents of other tabs

Reported by, Dec 19 2016

Issue description

Using WebGL, a malicious web page can capture the contents of other tabs
as images and upload them to a server. Reproducible on a Samsung Galaxy S6.
Probably MEDIUM severity.

Chrome Version: [55.0.2883.91] + [stable]
Operating System: [Android 6.0.1; SM-G920F Build/MMB29K] 
Samsung Galaxy S6 UK model.

Note that since the issue might only be reproducible on the Samsung Galaxy S6,
you may prefer to just read `` in the zip, which includes the reproduction instructions.
I attach `index.html`, a self-contained HTML file demonstrating the issue.
I also attach a zip archive with more details, the HTML file, 
and a self-contained Python 3 script that will serve the HTML file 
and will save the uploaded PNG image files captured by the HTML file.
It also includes some sample images to show what can be captured; 
these are also described in the
See for instructions and more details.

9.9 KB View Download
3.5 MB Download
Components: Internals>GPU>WebGL
Labels: Security_Severity-Medium Security_Impact-Stable OS-Android Pri-1
Status: Assigned (was: Unconfirmed)
I unfortunately don't have access to a Galaxy S6 to test this, but this looks like an interesting bug.

Ken, any ideas here? I'm wondering if there's any additional validation we could do.

Comment 2 by, Dec 19 2016

Components: Blink>WebGL
Labels: -Pri-1 -Security_Severity-Medium Security_Severity-Low Pri-2
I tested this on a Google Pixel and can't reproduce the capture of corrupted VRAM.

I'd like to understand better whether the browser thinks the WebGL context's been lost at the time toDataURL is called. If it is, we should return a blank image rather than attempting to actually perform the readback.

The problem appears to be related to the injection of this long-running no-op loop in the fragment shader:

      int GLF_live3i = 0;
      GLF_live3i < 12244;
      GLF_live3i ++

The first time I tried this test case on my MacBook Pro it caused a GPU hang and reset, but it wasn't reproducible afterward. I didn't have the server running (would be better if it was written in Python 2.x for macOS compatibility) but did see a flash of what looked like garbage VRAM.

Reducing to low security severity and P2 because evidence is that this affects only specific devices. We'd need one to diagnose this in more detail. Prudhvi, do we have an S6 in house that we can use for testing?


Comment 4 by, Dec 20 2016

I am fairly certain the WebGL context is not lost on the Samsung Galaxy S6. There is no popup and no refreshing occurred. 

The included fragment shader indeed probably only works for ARM Mali GPUs as in the Samsung Galaxy S6. I think some Sony Xperia phones may also have Mali GPUs, if that helps. 

A different fragment shader might be able to cause a similar issue on other GPUs. Sometimes adding a "discard" or early "return" statement (possibly conditional on a uniform) is enough to cause garbage. But in this case we indeed believe it is the long running loop. 

Changing the loop bound can also have an effect. E.g. a lower loop bound might not hang certain GPUs. Note that the loop bound could be provided in a uniform parameter, so a straightforward loop bound static analysis is unlikely to be enough to detect this. 

I attach an updated zip where `` works with Python 2 and 3.
3.5 MB Download

Comment 5 by, Dec 20 2016

Thanks. No garbage observed with your server on macOS 10.11.6 with Chrome 57.0.2956.0 (Official Build) canary (64-bit).

Ligi, Prudhvi, do we have a Samsung Galaxy S6 on which I could run a test? Ligi, assigning to you so this doesn't get dropped.


Comment 7 by, Dec 20 2016

Labels: -Pri-2 -Security_Severity-Low Security_Severity-Medium Pri-1
Status: ExternalDependency (was: Assigned)
Got the S6 (thanks Prudhvi), and confirm that garbage is observed when running the test case.

Upgrading this back to Security_Severity-Medium and P1. I think the information leak is significant.

Filed internal bug b/33757419 about this, in the bug category for the Mali GPU. I'll also contact a couple of colleagues at ARM and Samsung who may be able to help triage this.

My best guess is that the Mali GPU is aborting a long-running command buffer without signaling that the context is lost via the GL_KHR_robustness extension, although Chrome is allocating its contexts with that reset strategy turned on (visible in about:gpu). Chrome needs that reset notification in order to lose the WebGL context and prevent information leakage such as this. There is already code in place for this purpose.

I'm not sure what we can do about this yet. Marking ExternalDependency to indicate that we don't have any solutions yet from the Chrome side, and need feedback from ARM.

Project Member

Comment 8 by, Dec 20 2016

Labels: M-56

Comment 9 by, Jan 25 2017

Could I check the status of this?

1. Has the issue been reported to ARM? To whom? Has there been a response?
2. Has the issue been reported to Samsung? To whom? Has there been a response?
3. Can we get cc'ed in these conversations? And/or is there an id or reference number (from ARM/Samsung) we can use if we want to refer to these bug reports?
4. Do ARM and Samsung know that the shader was generated by fuzzing (using GLFuzz)?


I've asked those questions on our internal bug.  What I can share now is that Samsung is definitely aware of this; hopefully we can answer the rest of your questions in the near future.

kbr@, can you circle back once we have more details?

Comment 11 by, Jan 27 2017

Yes, I'll update this bug when either ARM or Samsung gets back to us.

Labels: reward-topanel
Project Member

Comment 13 by, Mar 10 2017

Labels: -M-56 M-57
Project Member

Comment 14 by, Apr 20 2017

Labels: -M-57 M-58
Project Member

Comment 15 by, Jun 6 2017

Labels: -M-58 M-59
Components: -Internals>GPU>WebGL

Comment 17 by, Jul 18 2017

Could I check on the status of this? 

Comment 18 by, Jul 18 2017

Asked ARM/Samsung for a status update on the internal bug b/33757419 .

Comment 19 by, Jul 19 2017

I can no longer reproduce this after updating my Samsung S6 (Europe). 
Android 7.0; SM-G920F Build/NRD90M

The rendered image is transparent and, sometimes, the context is lost (I see "Rats! WebGL hit a snag"). 

Comment 20 by, Jul 19 2017

Thanks. That's the expected behavior; KHR_robustness is supposed to lose the context in this situation. I've asked for confirmation on b/33757419 but most likely we'll have to close this as WontFix (no longer reproducible). Also, we never got a bug ID from ARM or Samsung.

Project Member

Comment 21 by, Jul 26 2017

Labels: -M-59 M-60
Thanks. We have confirmation from Samsung that they saw the bug report and confirmation from ARM that they saw the report and fixed the bug thanks to our report. 

Comment 23 by, Aug 8 2017

That's great news.

Comment 24 by, Aug 8 2017

Status: WontFix (was: ExternalDependency)
Closed the internal bug as Fixed, but closing this one as WontFix since we didn't make any code changes to Chromium in response, and since it's no longer reproducible after a rollout of Samsung's newest driver.

Project Member

Comment 25 by, Aug 8 2017

Labels: -reward-topanel reward-ineligible

Comment 26 by, Aug 10 2017

Is it possible to manually check if we are still eligible for a reward? My understanding of the program is that we might still be eligible. But I assume we are automatically marked as ineligible when the status is changed to WontFix. 

"Bugs may be eligible even if they are part of the base operating system and can manifest through Chrome."

"...bugs may be eligible even if they are caused by components of the operating system or standard libraries. We're interested in rewarding any information that enables us to better protect our users. In the event of bugs in an external component, we are happy to take care of responsibly notifying other affected parties."

Comment 27 by, Aug 10 2017

Labels: -reward-ineligible reward-topanel
Status: ExternalDependency (was: WontFix)
Oops. Sorry, didn't mean to break your eligibility for a reward, especially since the capture of content occurred through the browser.

Marking as ExternalDependency again and resetting the reward label.

Comment 28 by, Aug 10 2017

Thanks so much. Hopefully it is not necessary for the bug to be marked as Fixed/Verified to trigger the next stage of the reward process. If it is necessary, perhaps this bug can be manually flagged for review, as we believe it is fixed (and the fix is deployed) but this may not be clear. 
Status: Fixed (was: ExternalDependency)
Thanks!  Going to mark this as Fixed since the security issue is indeed fixed (this is in line with how we track this in similar situations, like security bugs in Flash).  The VRP panel will look at this soon.  Thanks!
Project Member

Comment 30 by, Aug 12 2017

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Project Member

Comment 31 by, Aug 14 2017

Labels: Merge-Request-61
Project Member

Comment 32 by, Aug 14 2017

Labels: -Merge-Request-61 Merge-Review-61 Hotlist-Merge-Review
This bug requires manual review: M61 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), ketakid@(ChromeOS), govind@(Desktop)

For more details visit - Your friendly Sheriffbot
Labels: -Merge-Review-61
Per c#24 there is nothing to merge here, but correct me if I'm wrong...

Comment 34 by, Aug 18 2017

That's right! I think the aim is to mark this as fixed, merged, etc. (whatever is appropriate), despite the fact that there are no changes to Chromium, so that the rewards panel will review this. I am not sure if some additional labels are needed. 
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.
Congratulations! The Chrome VRP panel decided to award $2,000 for this report. A member of our finance team will be in touch to arrange payment.
Labels: -reward-unpaid reward-inprocess
Thanks! We received the reward! Since the fix was actually released some time ago (I think probably around April 2017), is it possible to make this Chromium issue/report public so we can refer to it?
Project Member

Comment 39 by, Nov 18 2017

Labels: -Restrict-View-SecurityNotify allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot

Sign in to add a comment