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

Issue 376951 link

Starred by 1 user

Issue metadata

Status: Fixed
Closed: Jun 2014
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security

Sign in to add a comment

Security: webgl draw buffers extension can expose unitialized video memory to webpage

Reported by, May 23 2014

Issue description

Using the webgl draw buffers extension you can drawBuffers([gl.NONE]). This prevents the usual implicit clear that happens before new draws. This unitialized surface can then be read from.

Chrome Version: 35.0.1916.114 stable
Operating System: OS X 10.9

I've attached a modified version of the EXT_draw_buffers conformance test suite that shows the problem. You may need to refresh the page a couple of times and perhaps resize the window. Eventually you'll see content that looks like text or scroll bars in the canvas area.
24.7 KB Download

Comment 1 by, May 23 2014

Labels: Security_Severity-Medium Cr-Blink-WebGL OS-All Security_Impact-Stable Security_Impact-Beta Security_Impact-Head
Status: Assigned
zmo: could you please take a look or help find an owner for this?

Comment 2 by, May 23 2014

I'll fix this.

Thanks for reporting it.
Project Member

Comment 3 by ClusterFuzz, May 23 2014

Labels: -Security_Impact-Head Pri-1
Project Member

Comment 4 by ClusterFuzz, Jun 1 2014

Labels: Nag
zmo@: Uh oh! This issue is still open and hasn't been updated in the last 7 days. Since this is a serious security vulnerability, we want to make sure progress is happening. Can you update the bug with current status, and what, if anything, is blocking?

If you are not the right Owner for this bug, please find someone else to own it as soon as possible and remove yourself as Owner.

If the issue is already fixed or you are to unable to reproduce it, please close the bug. (And thanks for fixing the bug!).

These nags can be disabled by adding a 'WIP' label and an optional codereview link.

- Your friendly ClusterFuzz

Comment 5 by, Jun 2 2014

Labels: -Nag
Status: Started
if backbuffer's drawBuffers is set to GL_NONE, apparently we didn't set backbuffer to GL_COLOR_ATTACHMENT0 before clearing and then set to GL_NONE again.  However, there is some nastiness where drawBuffers() no longer has effects.  Still looking into why.
Project Member

Comment 6 by, Jun 6 2014

The following revision refers to this bug:

commit ee7579229ff7e9e5ae28bf53aea069251499d7da
Author: <>
Date: Fri Jun 06 05:21:42 2014

Framebuffer clear() needs to consider the situation some draw buffers are disabled.

This is when we expose DrawBuffers extension.

BUG= 376951 
TEST=the attached test case, webgl conformance,

Review URL:

git-svn-id: svn:// 0039d316-1c4b-4281-b951-d872f2087c98

Status: Fixed
Labels: M-36
Project Member

Comment 10 by ClusterFuzz, Jun 6 2014

Labels: -Restrict-View-SecurityTeam Merge-Triage Restrict-View-SecurityNotify M-35
Adding Merge-Triage label for tracking purposes.

Once your fix had sufficient bake time (on canary, dev as appropriate), please nominate your fix for merge by adding the Merge-Requested label.

When your merge is approved by the release manager, please start merging with higher milestone label first. Make sure to re-request merge for every milestone in the label list. You can get branch information on

- Your friendly ClusterFuzz
Labels: -M-35
zmo: Can you upstream this test into the webgl conformance suite when appropriate?

Comment 13 by, Jun 9 2014

Will do, but probably after we merge the fix back to M36 before releasing this vulnerability to the public. 

Comment 14 by, Jun 10 2014

Labels: -Merge-Triage Merge-Requested
Can you provide a better justification as to why this change must go into 36?  I would prefer if we punt this over to 37 due to the size and severity of your change.
FYI from a security perspective, we try to merge all medium-severity security fixes into Beta builds (and externally-reported Medium severity fixes into Stable builds).

If this merge is huge/hairy/scary and you want to punt it unless you get a justification on the severity of the issue, I'll leave it to those closer to the issue to comment. That said, I think it's reasonable to not take this fix into M36 without justification.

Comment 17 by, Jun 11 2014

There is lot of time for M-36 baking here. We can't punt a medium severity into M37 unless it is a complete code rewrite, large refactoring, etc.

Comment 18 by, Jun 12 2014

I think the security threat of this bug is low instead of medium.  Yes it does leak vram, but from what I see, it's garbage pixels from multisampled renderbuffers/textures.  It's very unlikely someone's able to exploit user info from this bug.
Labels: -Merge-Requested Merge-Rejected
Rejecting merge per comment 18.
Labels: reward-topanel

Comment 21 by, Jul 9 2014

Labels: -Merge-Rejected Merge-Triage
Labels: -M-36 M-37
If we're not going to merge this to M36, it's already in M37 as that was cut at r278856. 

inferno@ - please let me know if you want to see this in a M36 patch or if we can let this roll into M37 due to comments above.
yes based on c#18, we can let it roll in m37.
Labels: -Merge-Triage Release-0-M37 Merge-NA
Labels: -Security_Impact-Beta -reward-topanel reward-unpaid reward-2000 CVE-2014-3173
Thanks for the report! This qualifies for a $2000 reward. Someone should be reaching out to you soon with additional details.

How would you like to be credited when we mention this bug in our release notes?
Jeff Muizelaar <> is fine.

Comment 28 by, Sep 4 2014

Note that the test case is added in khronos webgl conformance suite:
Project Member

Comment 29 by ClusterFuzz, Sep 12 2014

Labels: -Restrict-View-SecurityNotify
Bulk update: removing view restriction from closed bugs.
Labels: -reward-unpaid reward-inprocess

I passed your details over to the finance team - they'll contact you directly to get your details for payment. If you haven't heard from them by this time next week, please contact me directly (or update this bug).

Congrats on the reward!

*** 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 established 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 31 by, Sep 30 2014

As far as I can see I've not received anything from the finance team.
Labels: -reward-inprocess reward-decline
As discussed with Jeff via email, we doubling this reward to $4000 and donating it to a charity. Thanks Jeff!
Project Member

Comment 33 by, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Project Member

Comment 34 by, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Labels: allpublic
Labels: CVE_description-submitted

Sign in to add a comment