Flapjack, 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 compromised renderer can send a maliciously large item_font_size via the ShowPopupMenu IPC to the browser process. This unvalidated value is passed to macOS text rendering APIs, which may trigger an integer overflow during buffer allocation. This can result in a heap buffer overflow in the unsandboxed browser or App Shim process.

Affected files:

• content/app_shim_remote_cocoa/web_menu_runner_mac.mm
• content/app_shim_remote_cocoa/render_widget_host_ns_view_bridge.mm
• content/browser/renderer_host/popup_menu_helper_mac.mm
• content/common/render_widget_host_ns_view.mojom

Estimated timestamp from git blame: 2024-02-09

Description

A potential heap buffer overflow exists in the macOS implementation of popup menus. The issue occurs because the font_size parameter passed from the renderer process via the blink.mojom.LocalFrameHost.ShowPopupMenu IPC is not validated or clamped by the browser process.

While Blink internally caps font sizes (e.g., to 10,000) during style resolution, a compromised renderer can bypass Blink and send an arbitrarily large double value (e.g., 1e30) directly over the Mojo IPC.

The browser process (RenderFrameHostImpl::ShowPopupMenu) receives this value and passes it unmodified through the PopupMenuHelper to the Remote Cocoa process via the RenderWidgetHostNSView::DisplayPopupMenu IPC. In content/app_shim_remote_cocoa/web_menu_runner_mac.mm, the unsanitized value is passed directly to the native macOS API:

attrs[NSFontAttributeName] = [NSFont menuFontOfSize:_fontSize];

When macOS AppKit and CoreGraphics prepare the menu for display, they compute the dimensions of the text to calculate the required backing store memory buffer (width * height * bytes_per_pixel). An astronomically large font size can cause this calculation to overflow the 64-bit integer limit, wrapping around to a small positive value. The system then allocates an undersized buffer. When CoreGraphics attempts to rasterize the massive glyphs into this small buffer, it results in an out-of-bounds write (Heap Buffer Overflow).

Because this UI rendering occurs in the unsandboxed browser process or App Shim process, memory corruption here can be leveraged to achieve a full sandbox escape and arbitrary code execution.

Potential Steps to Reproduce

Note: These are suggested steps for exploitation, as our tooling agent does not currently have the ability to run code to produce a working proof-of-concept.

1. An attacker compromises the renderer process (e.g., via a V8 vulnerability).
2. The compromised renderer connects to the blink.mojom.LocalFrameHost Mojo interface in the browser process.
3. The attacker calls the ShowPopupMenu method, providing a PopupMenuClient, bounds, and setting the font_size parameter to an extreme value like 1e30.
4. The browser process passes the value to the macOS App Shim process.
5. WebMenuRunner invokes [NSFont menuFontOfSize:1e30], triggering the OS-level integer overflow during menu rasterization and causing a heap buffer overflow.

Suggested Fix

Clamp the font_size parameter in RenderFrameHostImpl::ShowPopupMenu (in content/browser/renderer_host/render_frame_host_impl.cc) to a safe maximum before it is used or passed to platform-specific UI code. A maximum of 10000.0 would match Blink’s internal kMaximumAllowedFontSize and prevent malicious values from reaching the OS APIs.

Evaluated with Chrome root at commit: cc901875d53bf4e4fe0e01f02843871da4106e70

Results so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; 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.