Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports without the Chrome Security team. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A potential 32-bit integer overflow exists in Mojo’s ReadBuffer::Reserve function, allowing an attacker to bypass buffer reallocation logic. This can result in an out-of-bounds heap write in the browser process when processing crafted IPC messages from a compromised renderer. The issue specifically affects 32-bit platforms where size_t is 32 bits.

Affected files:

• mojo/core/channel.cc
• mojo/core/channel_posix.cc
• mojo/core/channel_win.cc
• mojo/core/channel.h

Estimated timestamp from git blame: 2022-08-15

Summary

A potential integer overflow vulnerability has been identified in mojo/core/channel.cc. On 32-bit architectures, the Channel::ReadBuffer::Reserve method can be induced to return a pointer that is out-of-bounds of its backing heap allocation. This occurs because the calculation used to determine if the buffer should grow can overflow, leading the code to incorrectly conclude that sufficient space is already available.

Root Cause Analysis

In mojo/core/channel.cc, the Channel::ReadBuffer::Reserve(size_t num_bytes) method is responsible for ensuring the read buffer has enough contiguous space for incoming data:

char* Reserve(size_t num_bytes) {
  if (num_occupied_bytes_ + num_bytes > size_) {
    // ... reallocation logic ...
  }
  return data_.subspan(num_occupied_bytes_).data();
}

On 32-bit systems, size_t is 32 bits. An attacker can control num_bytes (via a Mojo message header parsed in TryDispatchMessage) by providing a value such that num_occupied_bytes_ + num_bytes overflows and wraps around. For example, if the current buffer is full (num_occupied_bytes_ == size_ == 4096), and num_bytes is 0xFFFFFFFF, the sum wraps to 4095. Since 4095 > 4096 is false, the reallocation is skipped.

Reserve then returns data_.subspan(4096).data(), which is a pointer to the first byte immediately following the 4096-byte allocation.

Exploitation Potential

The transport layer (e.g., ChannelPosix or ChannelWin) uses the pointer returned by Reserve to read data from the IPC socket. In ChannelPosix::OnFdReadable:

char* buffer = GetReadBuffer(&buffer_capacity);
// ...
ssize_t read_result = SocketRecvmsg(socket_.get(), buffer, buffer_capacity, ...);

Here, buffer will be the out-of-bounds pointer, and buffer_capacity will be the original large num_bytes value. This allows a compromised renderer to perform a linear heap overflow in the unsandboxed browser process, which can be leveraged for a sandbox escape.

Suggested Fix

Use base::CheckedNumeric to perform the addition and comparison in ReadBuffer::Reserve safely to detect and handle potential overflows.

char* Reserve(size_t num_bytes) {
  base::CheckedNumeric<size_t> required_size = num_occupied_bytes_;
  required_size += num_bytes;
  if (!required_size.IsValid() || required_size.ValueOrDie() > size_) {
    // ... reallocation logic ...
  }
  return data_.subspan(num_occupied_bytes_).data();
}

Suggested Reproduction Steps

Note: These steps are theoretical as they have not been validated with a running PoC.

1. Target a 32-bit Chrome/WebView build (e.g., 32-bit Android or Windows x86).
2. From a compromised renderer, send a Mojo message where the header specifies a very large size (e.g., 0xFFFFFFFF).
3. Ensure the browser-side Mojo Channel has some data already in its ReadBuffer such that the addition overflows.
4. Send the overflow payload over the IPC channel. The browser should write this data past the end of the ReadBuffer allocation.

Evaluated with Chrome root at commit: b3153093eb3c78c3e88ccf562bcbc20437a04b0e

Results so far have been promising, but there can be wrong deductions. Feel free to adjust as follows:

• If you are familiar with the severity guidelines, you may adjust the severity.
• If this is a false positive, and there’s no work to be done, please close as WAI.
• If there is work to do here but not a vulnerability, please change the issue type to Task/Bug/FR.

Data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.