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

Issue 877182 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
please use my google.com address
Closed: Aug 28
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 1
Type: Bug-Security



Sign in to add a comment

Security: Mojo DataPipe*Dispatcher deserialization lacking validation

Project Member Reported by markbrand@google.com, Aug 23

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


 
consumer.diff
1.4 KB Download
Cc: jam@chromium.org
Owner: roc...@chromium.org
Status: Assigned (was: Unconfirmed)
Components: Internals>Mojo
Labels: Security_Impact-Stable OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows
Labels: Security_Severity-Medium
Labels: M-68
Project Member

Comment 5 by sheriffbot@chromium.org, Aug 25

Labels: Pri-1
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.
browser_oob_write.diff
1.2 KB Download
browser_oob_write.js
331 bytes View Download
browser_oob_write.txt
7.4 KB View Download
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
Cc: alexilin@chromium.org
Err, misread. Still, straightforward fix to ensure that write_offset + available_capacity does not exceed the mapped size during deserialization.
This should be a comprehensive fix: https://chromium-review.googlesource.com/c/chromium/src/+/1192922
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?
Project Member

Comment 11 by bugdroid1@chromium.org, 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

Status: Fixed (was: Assigned)
Labels: Merge-Request-69
Project Member

Comment 14 by sheriffbot@chromium.org, Aug 29

Labels: -Merge-Request-69 Merge-Review-69 Hotlist-Merge-Review
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
Cc: benmason@chromium.org
Project Member

Comment 16 by sheriffbot@chromium.org, Aug 29

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Cc: awhalley@chromium.org mbarbe...@chromium.org infe...@chromium.org
+inferno@ & mbarbella@ for M69 Merge review as awhalley@ is OOO. Pls note CL listed at #11 didn't make it to canary yet.
rockot@, pls merge the change listed at #11 to canary branch 3535 so we can trigger new canary from same branch. Thank you.
I'm trying to merge now to canary branch.
Project Member

Comment 20 by bugdroid1@chromium.org, Aug 29

Labels: merge-merged-3535
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

Triggered new canary 70.0.3535.5 with merge listed at #20. Pls verify this change on 70.0.3535.5 or higher.
Labels: -Merge-Review-69 Merge-Approved-69
Approving merge to M69 branch 3497 per internal mail thread. Pls merge ASAP. Thank you.
Project Member

Comment 23 by bugdroid1@chromium.org, Aug 30

Labels: -merge-approved-69 merge-merged-3497
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

Labels: Release-0-M69
Labels: -Security_Severity-Medium Security_Severity-High
Labels: CVE-2018-16068 CVE_description-missing
Project Member

Comment 27 by sheriffbot@chromium.org, Dec 5

Labels: -Restrict-View-SecurityNotify allpublic
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: -CVE_description-missing CVE_description-submitted

Sign in to add a comment