Security: Mojo DataPipe*Dispatcher deserialization lacking validation |
||||||||||||||||||||
Issue description
This template is ONLY for reporting security bugs. If you are reporting a
Download Protection Bypass bug, please use the "Security - Download
Protection" template. For all other reports, please use a different
template.
Please READ THIS FAQ before filing a bug: https://chromium.googlesource.com
/chromium/src/+/master/docs/security/faq.md
Please see the following link for instructions on filing security bugs:
https://www.chromium.org/Home/chromium-security/reporting-security-bugs
NOTE: Security bugs are normally made public once a fix has been widely
deployed.
VULNERABILITY DETAILS
There's missing validation in the deserialisation routines for both
DataPipeConsumerDispatcher and DataPipeProducerDispatcher, which take from
the incoming message a read_offset/write_offset respectively into shared memory.
Providing an offset outside the bounds of the allocated memory will then result
in an OOB read/write when the pipe is used.
// static
scoped_refptr<DataPipeProducerDispatcher>
DataPipeProducerDispatcher::Deserialize(const void* data,
size_t num_bytes,
const ports::PortName* ports,
size_t num_ports,
ScopedInternalPlatformHandle* handles,
size_t num_handles) {
if (num_ports != 1 || num_handles != 1 ||
num_bytes != sizeof(SerializedState)) {
return nullptr;
}
const SerializedState* state = static_cast<const SerializedState*>(data);
if (!state->options.capacity_num_bytes || !state->options.element_num_bytes ||
state->options.capacity_num_bytes < state->options.element_num_bytes) {
return nullptr;
}
NodeController* node_controller = Core::Get()->GetNodeController();
ports::PortRef port;
if (node_controller->node()->GetPort(ports[0], &port) != ports::OK)
return nullptr;
ScopedInternalPlatformHandle buffer_handle;
std::swap(buffer_handle, handles[0]);
auto region_handle =
CreateSharedMemoryRegionHandleFromInternalPlatformHandles(
std::move(buffer_handle), ScopedInternalPlatformHandle());
auto region = base::subtle::PlatformSharedMemoryRegion::Take(
std::move(region_handle),
base::subtle::PlatformSharedMemoryRegion::Mode::kUnsafe,
state->options.capacity_num_bytes,
base::UnguessableToken::Deserialize(state->buffer_guid_high,
state->buffer_guid_low));
auto ring_buffer =
base::UnsafeSharedMemoryRegion::Deserialize(std::move(region));
if (!ring_buffer.IsValid()) {
DLOG(ERROR) << "Failed to deserialize shared buffer handle.";
return nullptr;
}
scoped_refptr<DataPipeProducerDispatcher> dispatcher =
new DataPipeProducerDispatcher(node_controller, port,
std::move(ring_buffer), state->options,
state->pipe_id);
{
base::AutoLock lock(dispatcher->lock_);
// BUG: state->write_offset is not trustworthy!
dispatcher->write_offset_ = state->write_offset;
dispatcher->available_capacity_ = state->available_capacity;
dispatcher->peer_closed_ = state->flags & kFlagPeerClosed;
if (!dispatcher->InitializeNoLock())
return nullptr;
dispatcher->UpdateSignalsStateNoLock();
}
return dispatcher;
}
See the following code for the site of the OOB write
MojoResult DataPipeProducerDispatcher::WriteData(
const void* elements,
uint32_t* num_bytes,
const MojoWriteDataOptions& options) {
base::AutoLock lock(lock_);
if (!shared_ring_buffer_.IsValid() || in_transit_)
return MOJO_RESULT_INVALID_ARGUMENT;
if (in_two_phase_write_)
return MOJO_RESULT_BUSY;
if (peer_closed_)
return MOJO_RESULT_FAILED_PRECONDITION;
if (*num_bytes % options_.element_num_bytes != 0)
return MOJO_RESULT_INVALID_ARGUMENT;
if (*num_bytes == 0)
return MOJO_RESULT_OK; // Nothing to do.
if ((options.flags & MOJO_WRITE_DATA_FLAG_ALL_OR_NONE) &&
(*num_bytes > available_capacity_)) {
// Don't return "should wait" since you can't wait for a specified amount of
// data.
return MOJO_RESULT_OUT_OF_RANGE;
}
DCHECK_LE(available_capacity_, options_.capacity_num_bytes);
uint32_t num_bytes_to_write = std::min(*num_bytes, available_capacity_);
if (num_bytes_to_write == 0)
return MOJO_RESULT_SHOULD_WAIT;
*num_bytes = num_bytes_to_write;
CHECK(ring_buffer_mapping_.IsValid());
uint8_t* data = static_cast<uint8_t*>(ring_buffer_mapping_.memory());
CHECK(data);
const uint8_t* source = static_cast<const uint8_t*>(elements);
CHECK(source);
DCHECK_LE(write_offset_, options_.capacity_num_bytes);
uint32_t tail_bytes_to_write =
std::min(options_.capacity_num_bytes - write_offset_, num_bytes_to_write);
uint32_t head_bytes_to_write = num_bytes_to_write - tail_bytes_to_write;
DCHECK_GT(tail_bytes_to_write, 0u);
// BUG: OOB write here
memcpy(data + write_offset_, source, tail_bytes_to_write);
if (head_bytes_to_write > 0)
memcpy(data, source + tail_bytes_to_write, head_bytes_to_write);
DCHECK_LE(num_bytes_to_write, available_capacity_);
available_capacity_ -= num_bytes_to_write;
write_offset_ =
(write_offset_ + num_bytes_to_write) % options_.capacity_num_bytes;
watchers_.NotifyState(GetHandleSignalsStateNoLock());
base::AutoUnlock unlock(lock_);
NotifyWrite(num_bytes_to_write);
return MOJO_RESULT_OK;
}
Mojo is kind of complicated, so I haven't figured out yet whether you can reach
this OOB write in the browser process from a renderer, but you can reach the
corresponding OOB read in DataPipeConsumerDispatcher.
If you apply the patch and then build chrome, you should be able to trigger a
browser process crash (with a malformed message from the renderer) by visiting
https://googlechrome.github.io/samples/service-worker/basic/ and interacting
with the live demo.
This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available (whichever is earlier), the bug
report will become visible to the public.
VERSION
Chrome Version: stable
Operating System: [Please indicate OS, version, and service pack level]
REPRODUCTION CASE
Please include a demonstration of the security bug, such as an attached
HTML or binary file that reproduces the bug when loaded in Chrome. PLEASE
make the file as small as possible and remove any content not required to
demonstrate the bug.
FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION
Type of crash: browser
Crash State:
Received signal 11 SEGV_ACCERR 7f3a365a2000
#0 0x55efba71bc31 in __interceptor_backtrace /b/build/slave/linux_upload_clang/build/src/third_party/llvm/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:3980:13
#1 0x55efc1b42f9c in base::debug::StackTrace::StackTrace(unsigned long) /ssd/chrome/src/out/asan/../../base/debug/stack_trace_posix.cc:808:10
#2 0x55efc1b41f1d in PrintBacktraceOutputHandler /ssd/chrome/src/out/asan/../../base/debug/stack_trace_posix.cc:425:41
#3 0x55efc1b41f1d in Print /ssd/chrome/src/out/asan/../../base/debug/stack_trace_posix.cc:819:0
#4 0x55efc1b41f1d in base::debug::(anonymous namespace)::StackDumpSignalHandler(int, siginfo_t*, void*) /ssd/chrome/src/out/asan/../../base/debug/stack_trace_posix.cc:334:0
#5 0x7f3a4d8ae0c0 in __funlockfile ??:?
#6 0x7f3a4d8ae0c0 in ?? ??:0
#7 0x7f3a46b5c01e in memcpy /tmp/build-debs.Lfl5zt/glibc-2.24/string/../sysdeps/x86_64/multiarch/../multiarch/memmove-vec-unaligned-erms.S:360
#8 0x7f3a46b5c01e in ?? ??:0
#9 0x55efba7753b0 in __asan_memcpy _asan_rtl_:3
#10 0x55efbc4b9911 in mojo::edk::DataPipeConsumerDispatcher::ReadData(MojoReadDataOptions const&, void*, unsigned int*) /ssd/chrome/src/out/asan/../../mojo/edk/system/data_pipe_consumer_dispatcher.cc:171:7
#11 0x55efbc4aeb51 in mojo::edk::Core::ReadData(unsigned int, MojoReadDataOptions const*, void*, unsigned int*) /ssd/chrome/src/out/asan/../../mojo/edk/system/core.cc:851:22
#12 0x55efbd9ab9e6 in content::ServiceWorkerDataPipeReader::OnHandleGotSignal(unsigned int) /ssd/chrome/src/out/asan/../../content/browser/service_worker/service_worker_data_pipe_reader.cc:71:3
#13 0x55efc2e498f3 in get /ssd/chrome/src/out/asan/../../base/memory/weak_ptr.h:243:12
#14 0x55efc2e498f3 in operator bool /ssd/chrome/src/out/asan/../../base/memory/weak_ptr.h:256:0
#15 0x55efc2e498f3 in mojo::SimpleWatcher::OnHandleReady(int, unsigned int, mojo::HandleSignalsState const&) /ssd/chrome/src/out/asan/../../mojo/public/cpp/system/simple_watcher.cc:275:0
#16 0x55efc2e4a1d8 in HandleSignalsState /ssd/chrome/src/out/asan/../../mojo/public/cpp/system/handle_signals_state.h:23:23
#17 0x55efc2e4a1d8 in mojo::SimpleWatcher::Context::Notify(unsigned int, MojoHandleSignalsState, unsigned int) /ssd/chrome/src/out/asan/../../mojo/public/cpp/system/simple_watcher.cc:97:0
#18 0x55efc2e47a8b in mojo::SimpleWatcher::Context::CallNotify(MojoTrapEvent const*) /ssd/chrome/src/out/asan/../../mojo/public/cpp/system/simple_watcher.cc:59:23
#19 0x55efbc4ffd11 in mojo::edk::WatcherDispatcher::InvokeWatchCallback(unsigned long, unsigned int, mojo::edk::HandleSignalsState const&, unsigned int) /ssd/chrome/src/out/asan/../../mojo/edk/system/watcher_dispatcher.cc:91:1
#20 0x55efbc4feb03 in Unlock /ssd/chrome/src/out/asan/../../base/synchronization/lock_impl.h:70:12
#21 0x55efbc4feb03 in Release /ssd/chrome/src/out/asan/../../base/synchronization/lock.h:27:0
#22 0x55efbc4feb03 in ~AutoLock /ssd/chrome/src/out/asan/../../base/synchronization/lock.h:122:0
#23 0x55efbc4feb03 in mojo::edk::Watch::InvokeCallback(unsigned int, mojo::edk::HandleSignalsState const&, unsigned int) /ssd/chrome/src/out/asan/../../mojo/edk/system/watch.cc:79:0
#24 0x55efbc4f2627 in mojo::edk::RequestContext::~RequestContext() /ssd/chrome/src/out/asan/../../mojo/edk/system/request_context.cc:67:5
#25 0x55efbc4d39ab in mojo::edk::NodeChannel::OnChannelMessage(void const*, unsigned long, std::__1::vector<mojo::edk::ScopedInternalPlatformHandle, std::__1::allocator<mojo::edk::ScopedInternalPlatformHandle> >) /ssd/chrome/src/out/asan/../../mojo/edk/system/node_channel.cc:758:1
#26 0x55efbc4a2859 in mojo::edk::Channel::OnReadComplete(unsigned long, unsigned long*) /ssd/chrome/src/out/asan/../../mojo/edk/system/channel.cc:733:18
#27 0x55efbc5135bc in mojo::edk::(anonymous namespace)::ChannelPosix::OnFileCanReadWithoutBlocking(int) /ssd/chrome/src/out/asan/../../mojo/edk/system/channel_posix.cc:0:13
#28 0x55efc1b789b0 in base::MessagePumpLibevent::OnLibeventNotification(int, short, void*) /ssd/chrome/src/out/asan/../../base/message_loop/message_pump_libevent.cc:0:13
#29 0x55efc1b917b9 in event_process_active /ssd/chrome/src/out/asan/../../base/third_party/libevent/event.c:382:14
#30 0x55efc1b917b9 in event_base_loop /ssd/chrome/src/out/asan/../../base/third_party/libevent/event.c:521:0
#31 0x55efc1b79192 in base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) /ssd/chrome/src/out/asan/../../base/message_loop/message_pump_libevent.cc:215:17
#32 0x55efc1a2ba52 in base::RunLoop::Run() /ssd/chrome/src/out/asan/../../base/run_loop.cc:109:1
#33 0x55efbce15dbe in content::BrowserProcessSubThread::IOThreadRun(base::RunLoop*) /ssd/chrome/src/out/asan/../../content/browser/browser_process_sub_thread.cc:180:1
#34 0x55efc1ab1a45 in base::Thread::ThreadMain() /ssd/chrome/src/out/asan/../../base/threading/thread.cc:341:14
#35 0x55efc1b70f65 in CurrentId /ssd/chrome/src/out/asan/../../base/threading/platform_thread_posix.cc:142:10
#36 0x55efc1b70f65 in base::(anonymous namespace)::ThreadFunc(void*) /ssd/chrome/src/out/asan/../../base/threading/platform_thread_posix.cc:80:0
#37 0x7f3a4d8a4494 in start_thread ??:0:0
#38 0x7f3a46bc0a8f in clone ??:0:0
r8: 000000000000000a r9: fffff018415e5c03 r10: 00000fe7bea1a453 r11: 0000000000000008
r12: 0000000000000000 r13: 000000000000029c r14: 00007f3a365a2000 r15: 00007f39f5112000
di: 00007f39f5112000 si: 00007f3a365a2000 bp: 00007f3a37dffd30 bx: 000055efd331e248
dx: 000000000000029c ax: 00007f39f5112000 cx: 0000000000000000 sp: 00007f3a37dff4d8
ip: 00007f3a46b5c01e efl: 0000000000010287 cgf: 002b000000000033 erf: 0000000000000004
trp: 000000000000000e msk: 0000000000000000 cr2: 00007f3a365a2000
,
Aug 23
,
Aug 24
,
Aug 25
,
Aug 25
,
Aug 27
I have a browser process write from the renderer now. To reproduce, apply the attached patch, and then in the first tab run the attached javascript, and this should probably crash. Since it's just writing directly after the mapped shared memory, the crash is not deterministic, but I've attached the ASAN log from running locally under gdb, which makes it more observable for me.
,
Aug 28
IIRC (and AFAICT looking at the code), the assumption has always been that we would fail to map the memory if the communicated size were larger than the actual buffer object. Thus we should hit this failure mode[1] and ultimately reject the handle on deserialization. That appears to be an incorrect assumption now, so InitializeNoLock() should also validate the mapped size vs the specified size too. Will make that change. [1] https://cs.chromium.org/chromium/src/mojo/core/data_pipe_consumer_dispatcher.cc?rcl=d143f76c406803239e216b67e89b420f9a546e8a&l=442
,
Aug 28
Err, misread. Still, straightforward fix to ensure that write_offset + available_capacity does not exceed the mapped size during deserialization.
,
Aug 28
This should be a comprehensive fix: https://chromium-review.googlesource.com/c/chromium/src/+/1192922
,
Aug 28
I think this bug should probably be Severity-High? I don't think that your fix is sufficient to prevent a malicious renderer from exhausting browser process VA space - I was testing this yesterday and the renderer can also simply request some 1gig mappings and cause the browser process to crash. I think that's harder to fix (since AFAICT at least this code https://cs.chromium.org/chromium/src/base/memory/platform_shared_memory_region_posix.cc doesn't have any way to determine the true size of the shared memory region being mapped), and might be worth filing a separate lower severity issue for?
,
Aug 28
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/66e24a8793615bd9d5c238b1745b093090e1f72d commit 66e24a8793615bd9d5c238b1745b093090e1f72d Author: Ken Rockot <rockot@chromium.org> Date: Tue Aug 28 15:10:08 2018 [mojo-core] Validate data pipe endpoint metadata Ensures that we don't blindly trust specified buffer size and offset metadata when deserializing data pipe consumer and producer handles. Bug: 877182 Change-Id: I30f3eceafb5cee06284c2714d08357ef911d6fd9 Reviewed-on: https://chromium-review.googlesource.com/1192922 Reviewed-by: Reilly Grant <reillyg@chromium.org> Commit-Queue: Ken Rockot <rockot@chromium.org> Cr-Commit-Position: refs/heads/master@{#586704} [modify] https://crrev.com/66e24a8793615bd9d5c238b1745b093090e1f72d/mojo/core/data_pipe_consumer_dispatcher.cc [modify] https://crrev.com/66e24a8793615bd9d5c238b1745b093090e1f72d/mojo/core/data_pipe_producer_dispatcher.cc
,
Aug 28
,
Aug 29
,
Aug 29
This bug requires manual review: We are only 5 days from stable. Please contact the milestone owner if you have questions. Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 29
,
Aug 29
,
Aug 29
+inferno@ & mbarbella@ for M69 Merge review as awhalley@ is OOO. Pls note CL listed at #11 didn't make it to canary yet.
,
Aug 29
rockot@, pls merge the change listed at #11 to canary branch 3535 so we can trigger new canary from same branch. Thank you.
,
Aug 29
I'm trying to merge now to canary branch.
,
Aug 29
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0004aafc512d1033c44401200f7cf94dc2dee209 commit 0004aafc512d1033c44401200f7cf94dc2dee209 Author: Ken Rockot <rockot@chromium.org> Date: Wed Aug 29 16:05:06 2018 [mojo-core] Validate data pipe endpoint metadata Ensures that we don't blindly trust specified buffer size and offset metadata when deserializing data pipe consumer and producer handles. Bug: 877182 Change-Id: I30f3eceafb5cee06284c2714d08357ef911d6fd9 Reviewed-on: https://chromium-review.googlesource.com/1192922 Reviewed-by: Reilly Grant <reillyg@chromium.org> Commit-Queue: Ken Rockot <rockot@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#586704}(cherry picked from commit 66e24a8793615bd9d5c238b1745b093090e1f72d) Reviewed-on: https://chromium-review.googlesource.com/1195651 Reviewed-by: Krishna Govind <govind@chromium.org> Cr-Commit-Position: refs/branch-heads/3535@{#7} Cr-Branched-From: 4d18295073a6bf8f2f4d26e4e059767e091eaaf3-refs/heads/master@{#586474} [modify] https://crrev.com/0004aafc512d1033c44401200f7cf94dc2dee209/mojo/core/data_pipe_consumer_dispatcher.cc [modify] https://crrev.com/0004aafc512d1033c44401200f7cf94dc2dee209/mojo/core/data_pipe_producer_dispatcher.cc
,
Aug 29
Triggered new canary 70.0.3535.5 with merge listed at #20. Pls verify this change on 70.0.3535.5 or higher.
,
Aug 30
Approving merge to M69 branch 3497 per internal mail thread. Pls merge ASAP. Thank you.
,
Aug 30
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6502ac5eb169f3356f777b65470f9cfdd534173d commit 6502ac5eb169f3356f777b65470f9cfdd534173d Author: Ken Rockot <rockot@chromium.org> Date: Thu Aug 30 14:39:11 2018 [mojo-core] Validate data pipe endpoint metadata Ensures that we don't blindly trust specified buffer size and offset metadata when deserializing data pipe consumer and producer handles. TBR=rockot@chromium.org (cherry picked from commit 66e24a8793615bd9d5c238b1745b093090e1f72d) Bug: 877182 Change-Id: I30f3eceafb5cee06284c2714d08357ef911d6fd9 Reviewed-on: https://chromium-review.googlesource.com/1192922 Reviewed-by: Reilly Grant <reillyg@chromium.org> Commit-Queue: Ken Rockot <rockot@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#586704} Reviewed-on: https://chromium-review.googlesource.com/1196554 Reviewed-by: Ken Rockot <rockot@chromium.org> Cr-Commit-Position: refs/branch-heads/3497@{#847} Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753} [modify] https://crrev.com/6502ac5eb169f3356f777b65470f9cfdd534173d/mojo/core/data_pipe_consumer_dispatcher.cc [modify] https://crrev.com/6502ac5eb169f3356f777b65470f9cfdd534173d/mojo/core/data_pipe_producer_dispatcher.cc
,
Sep 4
,
Sep 4
,
Sep 4
,
Dec 5
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
,
Jan 4
|
||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||
Comment 1 by vakh@chromium.org
, Aug 23Owner: roc...@chromium.org
Status: Assigned (was: Unconfirmed)