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: The OpenXrRenderLoop class fails to initialize the stage_parameters_id_ member variable, causing a 4-byte information leak. This uninitialized heap memory is transmitted via Mojo from the Browser or Utility process to the Renderer. A compromised renderer could use this leak to obtain heap addresses and bypass ASLR.

Affected files:

• device/vr/openxr/openxr_render_loop.h
• device/vr/openxr/openxr_render_loop.cc
• device/vr/openxr/openxr_device.cc

Estimated timestamp from git blame: 2020-10-13

Description

A potential information disclosure vulnerability exists in the OpenXR implementation in Chromium. The OpenXrRenderLoop class does not initialize its stage_parameters_id_ member, leading to the transmission of 4 bytes of uninitialized heap memory from the Browser (on Android) or the XR utility process (on Windows) to the Renderer process via Mojo IPC.

Technical Details

In device/vr/openxr/openxr_render_loop.h, the member stage_parameters_id_ is declared as a uint32_t without an in-class initializer. The class constructor in device/vr/openxr/openxr_render_loop.cc also fails to initialize this member.

When OpenXrRenderLoop is instantiated (e.g., via std::make_unique in OpenXrDevice::OnCreateInstanceResult), the stage_parameters_id_ member is left with an indeterminate value from the previous heap contents. During the processing of a frame in OpenXrRenderLoop::GetFrameData, the following occurs:

1. StartPendingFrame is called, which eventually triggers UpdateStageParameters and SetStageParameters.
2. In the common case where bounded-floor parameters are either unavailable or haven’t changed from the initial null state, SetStageParameters returns early due to a check against current_stage_parameters_ (which is null by default), leaving stage_parameters_id_ uninitialized.
3. If parameters are updated, the code performs stage_parameters_id_++ at line 262, which results in another indeterminate value (incrementing uninitialized memory).
4. GetFrameData then reads this value at line 198 and assigns it to the XRFrameData Mojo struct: pending_frame_->frame_data_->stage_parameters_id = stage_parameters_id_;.

This value is then sent to the renderer process. A compromised renderer can observe these 4 bytes, which may contain sensitive pointers or other heap data from the more privileged parent process.

Potential Impact

This vulnerability allows a compromised renderer to leak 4 bytes of heap memory per WebXR session. On Android, this leak originates directly from the Browser process. This primitive can be used to defeat ASLR, facilitating further exploitation of the Browser or Utility process. This issue is mitigated by the requirement for a user gesture to initiate a WebXR session.

Suggested Exploit Steps (Potential)

These steps are theoretical and based on code analysis:

1. Compromise a Renderer process through an independent vulnerability.
2. Initiate a WebXR session (requires a user gesture).
3. Call the GetFrameData method of the XRFrameDataProvider Mojo interface.
4. Read the stage_parameters_id field from the returned XRFrameData struct.
5. Observe that the value contains 4 bytes of heap memory from the parent process.
6. Repeat with new sessions to sample the heap and reconstruct pointers.

Suggested Fix

Explicitly initialize stage_parameters_id_ to 0 in the class declaration in device/vr/openxr/openxr_render_loop.h:

// device/vr/openxr/openxr_render_loop.h
uint32_t stage_parameters_id_ = 0;

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.