CVE-2022-28285 - Understanding an Out-of-Bounds Bug in Firefox and Thunderbird

In early 2022, the security community uncovered a serious bug tracked as CVE-2022-28285, which affected popular Mozilla software like Firefox (before version 99), Thunderbird (before 91.8), and Firefox ESR (before 91.8). This vulnerability revolved around how these applications generated assembly code for a specific function called MLoadTypedArrayElementHole. In this post, we’ll break down what happened, what it means, and how it could be exploited with some easy-to-understand explanations, code snippets, and references to the official advisories.

What Actually Happened?

At the core, this bug was about generating assembly code for handling access to a certain type of memory array in JavaScript — specifically, *typed arrays*. Typed arrays in JavaScript let you deal with raw binary data. The function MLoadTypedArrayElementHole is used internally by the Firefox JavaScript engine (called SpiderMonkey) to safely load an element at a specific index. If you ask for a value outside the array’s bounds, it should, under secure operation, just return "undefined" or something safe.

But due to an incorrect AliasSet — basically, a way of telling the code generator which locations in memory might get changed or read — the browser could make mistakes when optimizing and reordering code. As a result, in combination with another bug, it became possible to trick the browser into *reading memory that was out of bounds* (OOB). This can lead to potential leaks of sensitive information or even facilitate harsher attacks like sandbox escapes or remote code execution under the right circumstances.

What’s an AliasSet?

In compilers and code generators, an AliasSet is a piece of information that tells the system what parts of memory a certain operation might touch. For example, reading from array A should not affect array B unless they overlap, so the AliasSet helps the optimizer keep things efficient without causing bugs. If you mess up the AliasSet relation, you can reorder code or combine steps that shouldn’t be combined, which is exactly what happened here.

In technical terms: MLoadTypedArrayElementHole accidentally used an incorrect AliasSet, making the code generator believe it was safe to fetch data from memory that might not have been initialized or, worse, is outside the expected array.

Code Snippet — The Vulnerable Part

Let's take a peek behind the curtains. Here’s a simplified snippet showing the relevant piece in Mozilla’s JavaScript engine (adapted for clarity):

// In the original code (before the fix)
MInstruction* load = MLoadTypedArrayElementHole::New(...);
// The AliasSet usage here was incorrect, which could cause
// the wrong memory to be accessed after optimization.
AliasSet set = AliasSet::Store(AliasSet::TypedArrayElement);
// ... rest of code ...

The fix involved making sure the right AliasSet is used, so the engine knows exactly what can be affected:

// After the fix
AliasSet set = AliasSet::Load(AliasSet::TypedArrayElement);
// Now code knows this is only reading from (not writing to) the array

This *tiny change* made a world of difference in how code is optimized and executed.

Exploit Details — How Could It Be Used?

On its own, this vulnerability was not directly exploitable. But, as the Mozilla Security Advisory notes:

> "When generating the assembly code for MLoadTypedArrayElementHole, an incorrect AliasSet was used. In conjunction with another vulnerability this could have been used for an out of bounds memory read."

What does this mean?

- Chaining with Another Bug: For an attacker to pull off a real exploit, they’d need another bug that can, for example, corrupt an array’s "length" property or other in-memory checks so the browser thinks the typed array is bigger than it really is.
- With that, and this CVE in play, you could write JavaScript code that asks for (say) the 100th slot of a 10-element array, and instead of a safe error, the browser could return a chunk of memory far past the array’s actual data.
- This could leak passwords, crypto keys, or other sensitive stuff in browser memory and might also help to bypass security boundaries.

Here's a pseudocode exploit chain (simplified for demonstration)

// Assume there's another bug to corrupt length
let typedArray = new Uint8Array(10);
typedArray.length = 100;  // This should not be allowed!

// Now, due to CVE-2022-28285, this could read out-of-bounds memory
let secret = typedArray[1337];

console.log("Leaked value:", secret);

Important: By itself, this CVE does NOT let you overwrite memory or execute code — but it leaves the browser open to data leaks through out-of-bounds reads.

Firefox ESR: Version 91.7 and all below

Upgrading to the latest version patches this specific bug.

Links to References

- Mozilla Security Advisory 2022-15 (CVE-2022-28285)
- CVE Details: CVE-2022-28285
- Bugzilla Entry (may contain more technical details)

Conclusion

CVE-2022-28285 is a great example of how a single line of code — or even a one-word change — can make a browser either secure or dangerously fragile. If you’re interested in browser security, it pays to keep an eye on these low-level details. And if you’re a user, always keep your software updated, because attackers are always on the hunt for such chained exploit opportunities.

Timeline

Published on: 12/22/2022 20:15:00 UTC
Last modified on: 12/30/2022 20:46:00 UTC