Full Report
Google Chrome is a browser that runs everywhere. Chromium is the open source browser engine underneath of Chrome that underlies Chrome, Edge, Brave and many more browsers. The post is about a memory safety issue that they found in the Chromium engine. The blog post really pushes towards autonomous security reviews because of the amount of new code that is being pushed. I understand the sentiment but not a huge fan of how it's pushed in the article. WebXR is an API for virtual and augmented reality experiences in the browser. It's a great target to hit for memory safety issues because of the complexity. It's an evolving API that's under active development and is interfacing with complex 3D graphics plus new hardware components. Applications can manipulate positions, rotations and transformations using interfaces that represent data in a 3D space. The vulnerable code path is around WebXR's matrix caching and JavaScript's ArrayBuffer semantics. A page can detach a typed array by transferring its underlying buffer to another context. This is a legitimate API and is used for zero-copy data transfers. When handling the case of a cached array being detached, the Chromium engine had a bad fallback. It returns a freshly created zero-length array. So, what's the problem? During this code path, there's only a length check on the size in DEBUG builds. So, when ColMajorF accessing 16 array indexes, it reads 64 bytes past the end of the buffer that was just initialized. This creates an out of bounds read in the Chromium Engine. To fix the vulnerability, the matrix is recalculated from the authoritative internal state instead of the cached array. This is in accordance to the WebXR specification. The Aisle tool additionally found two other locations where this was happening but the exploitability isn't mentioned in the article.
Analysis Summary