Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Starred by 1 user

Status: Fixed Mar 2015 Blink>WebGL ---- ---- ---- 1 Bug-Security

Reported by w3bd3...@gmail.com, Mar 3 2015

### Issue description

Running Chromium with --no-sandbox reproduces the issue

VULNERABILITY DETAILS
[0304/012123:ERROR:client_util.cc(258)] Could not find exported function RelaunchChromeBrowserWithNewCommandLineIfNeeded
#0 0x111ef9b1 in WTF::String::fromUTF8 C:\b\build\slave\Win_ASan_Release\build\src\third_party\WebKit\Source\wtf\text\ASCIIFastPath.h:91
#6 0x11f8d5e8 in v8::internal::FunctionCallbackArguments::Call C:\b\build\slave\Win_ASan_Release\build\src\v8\src\arguments.cc:33
#7 0x11b2a9fb in v8::internal::Builtins::InvokeApiFunction C:\b\build\slave\Win_ASan_Release\build\src\v8\src\builtins.cc:1077
#8 0x11b3777b in v8::internal::Builtins::Builtins C:\b\build\slave\Win_ASan_Release\build\src\v8\src\builtins.cc:1100

0x04c7d0d1 is located 0 bytes to the right of 1-byte region [0x04c7d0d0,0x04c7d0d1)
#0 0x1074bf8 in malloc c:\b\build\slave\win_asan_release\build\src\third_party\llvm\projects\compiler-rt\lib\asan\asan_malloc_win.cc:58
#1 0x1bd6140d in operator new f:\dd\vctools\crt\crtw32\heap\new.cpp:59
#6 0x11f8d5e8 in v8::internal::FunctionCallbackArguments::Call C:\b\build\slave\Win_ASan_Release\build\src\v8\src\arguments.cc:33
#7 0x11b2a9fb in v8::internal::Builtins::InvokeApiFunction C:\b\build\slave\Win_ASan_Release\build\src\v8\src\builtins.cc:1077
#8 0x11b3777b in v8::internal::Builtins::Builtins C:\b\build\slave\Win_ASan_Release\build\src\v8\src\builtins.cc:1100

VERSION
Chrome Version: Version 43.0.2321.0 (asan-win32-release-318863)
Operating System: Windows

I have also tested this to work with Linux 64bit.


Attaching the ASAN log on linux.

 Cc: timwillis@chromium.org kbr@chromium.org Labels: Security_Severity-High reward-topanel Owner: zmo@chromium.org Status: Assigned
Thanks a lot Omair for the report. Good to see you back! If you are interested in the Fuzzer Contribution Program on ClusterFuzz, definitely ping me, i can get you started.

ClusterFuzz is analyzing your testcase. Chromium developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=5663809184727040

ClusterFuzz is analyzing your testcase. Chromium developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=5793631886114816

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=5663809184727040

Job Type: Windows_asan_chrome

Crash State:

Regressed: https://cluster-fuzz.appspot.com/revisions?job=windows_asan_chrome&range=319249:319250


Detailed report: https://cluster-fuzz.appspot.com/testcase?key=5793631886114816

Job Type: Linux_asan_chrome_mp

Crash State:


Could you please attach about:gpu output from the affected machines?

It looks to me like there is a bug in the OpenGL driver where it is not leaving the return values from glGetActiveUniform untouched as it should when an error is produced, as this test case does. The test case attempts to fetch an active uniform whose index is out of range.


Attached the output as requested.

I don't have access to the minimized testcase.


please go to the report link [https://cluster-fuzz.appspot.com/testcase?key=5663809184727040] to access

 Cc: siev...@chromium.org piman@chromium.org
OK, I think I fully understand the out-of-bound visit case.

We link a program successfully, then detach a shader, and try to relink.  Now we generate an error in command buffer, knowing that a shader is missing from the program.  However, in the driver the program is still valid with all states, because the failed link call never reaches there.

Now, we call getActiveUniform.  In the client side cache, we have zero active uniforms (this is correct), so we turn to service side in the hope to generate an GL error (This is an overdo in my eyes).  On the service side, we actually return with the information because the program on the driver is still valid.

SO where the out-of-bound write happens, is WebGraphicsContext3DImpl::getActiveUniform() on the client side, where we query the maximum uniform name length, which returns 1 (from cached states).  But the service side instead of generating an error, it returns a name that's beyond the buffer (size of 1) to hold the name, therefore, out-of-bound write.

My proposal to fix this bug:

1) Always trust the cache, and generate an error on client side if cache indicates the query is invalid (for example, uniform index is out of bound).

2) We can actually delete all these individual query commands from the command buffer.  Because all the successful queries got their info from the client side cache, which is returned by the internal CHROMIUM super commands (lie GetProgramInfo, etc).  The only use of such individual query commands is for generate an error, and from here, they are not event doing that job successfully.  SO what we do with them?  Termination!

 Status: Started
Once we fix this bug and merge back to various releases, I'll add more test cases to WebGL conformance tests.  It's hard to believe we have such cases untested.

The following revision refers to this bug:

Author: zmo <zmo@chromium.org>
Date: Mon Mar 09 22:13:19 2015

Fix glGetActiveUniform/Attrib crashes due to state inconsistency

between what Chrome thinks and what the driver is.

This is caused by we intercept invalid program and generate an error on
LinkProgram rather than passing it to the driver, so the driver still have
a valid program if the previous link succeeds.

BUG= 463599
TEST=test case in the bug
R=sievers@chromium.org

Review URL: https://codereview.chromium.org/978193003


 Status: Fixed
 Labels: Merge-Requested M-42 M-41
I think this should be merged back to all branches alive.

 Labels: -Merge-Requested Merge-Triage
zmo: I can take care of the merge requests for you (after the fix has had some bake time on trunk).

The following revision refers to this bug:

commit ac89bdd636a4a6d8f15415e69b40e546cb020567
Author: zmo <zmo@chromium.org>
Date: Tue Mar 10 02:09:05 2015

Add a mechanism for command buffer to conditionally allow ES3 enums.

Although ultimately we want to remove validators from command buffer, but the
fastest way to allow an experimental WebGL 2 is actually appending the current
validators.

Appended the BufferTarget as an sample to make sure code generator works.

BUG= 463599
TEST=gpu_unittests, webgl conformance tests
R=sievers@chromium.org

Review URL: https://codereview.chromium.org/987123003

[modify] http://crrev.com/ac89bdd636a4a6d8f15415e69b40e546cb020567/gpu/command_buffer/build_gles2_cmd_buffer.py
[modify] http://crrev.com/ac89bdd636a4a6d8f15415e69b40e546cb020567/gpu/command_buffer/common/gles2_cmd_utils_implementation_autogen.h
[modify] http://crrev.com/ac89bdd636a4a6d8f15415e69b40e546cb020567/gpu/command_buffer/service/feature_info.cc
[modify] http://crrev.com/ac89bdd636a4a6d8f15415e69b40e546cb020567/gpu/command_buffer/service/feature_info.h
[modify] http://crrev.com/ac89bdd636a4a6d8f15415e69b40e546cb020567/gpu/command_buffer/service/gles2_cmd_decoder.cc
[modify] http://crrev.com/ac89bdd636a4a6d8f15415e69b40e546cb020567/gpu/command_buffer/service/gles2_cmd_validation.h
[modify] http://crrev.com/ac89bdd636a4a6d8f15415e69b40e546cb020567/gpu/command_buffer/service/gles2_cmd_validation_implementation_autogen.h


ClusterFuzz has detected this issue as fixed in range 319619:319868.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=5793631886114816

Job Type: Linux_asan_chrome_mp

Crash State:

Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_asan_chrome_mp&range=319619:319868

If you suspect that the result above is incorrect, try re-doing that job on the testcase report page.


 Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
 Labels: Security_Impact-Stable
 Labels: -Merge-Triage Merge-Requested
Merge Requested to M42

 Labels: -Merge-Requested Merge-Review Hotlist-Merge-Review
[Automated comment] Request affecting a post-stable build (M41), manual review required.

 Labels: Merge-Approved Hotlist-Merge-Approved
Approved for M42 (branch: 2311)

 Labels: -Merge-Review -Hotlist-Merge-Review
Merge approved for m41 branch 2272.

@zmo - please merge to M42 (branch 2311). Please hold off of the merge to M41 until we have some beta coverage.

Note: @zmo is out of the office for a few weeks. We should find someone else to do this merge.


 Labels: -Merge-Approved merge-merged-2311
The following revision refers to this bug:

commit 73f24f1ef5e222566a84070887eb5120cdef55e8
Author: Will Harris <wfh@chromium.org>
Date: Fri Mar 27 22:31:05 2015

Merge: Fix glGetActiveUniform/Attrib crashes due to state inconsistency

between what Chrome thinks and what the driver is.

This is caused by we intercept invalid program and generate an error on
LinkProgram rather than passing it to the driver, so the driver still have
a valid program if the previous link succeeds.

BUG= 463599
TEST=test case in the bug
R=sievers@chromium.org

Review URL: https://codereview.chromium.org/978193003

Review URL: https://codereview.chromium.org/1039423002


 Labels: -M-41 Release-0-M42
Thanks wfh!

Removing M41 target as it's too late for that milestone.

 Labels: -Security_Severity-High Security_Severity-Medium
 Labels: -reward-topanel reward-unpaid reward-1000 CVE-2015-1240
Congrats w3bd3vil - Our panel decided to reward you with \$1000 for this report!

Someone from our finance area should be in contact in two weeks to collect payment details. Please contact me directly if this doesn't happen.

We'll credit you in our release notes as w3bd3vil. Please let me know if you'd like to use another name.

Cheers,
Tim

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

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

 Labels: -reward-inprocess
Processing via our e-payment system can take up to two weeks, but the reward should be on its way to you. Thanks again for your help!

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

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

 Labels: allpublic
 Labels: CVE_description-submitted
 Labels: Pri-1