Firefox 124.0.1 fixes two critical JavaScript engine vulnerabilities

                							

                <!--X-Body-Begin-->
<!--X-User-Header-->

oss-sec
mailing list archives
<!--X-User-Header-End-->
<!--X-TopPNI-->

By Date

By Thread

</form>

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
Firefox 124.0.1 fixes two critical JavaScript engine vulnerabilities

<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->

From: Solar Designer &lt;solar () openwall com&gt;

Date: Sat, 23 Mar 2024 15:14:35 +0100

<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->

<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
Hi,

As successfully demonstrated by Manfred Paul at Pwn2Own:

https://www.mozilla.org/en-US/security/advisories/mfsa2024-15/

# CVE-2024-29943: Out-of-bounds access via Range Analysis bypass

Reporter      Manfred Paul via Trend Micro's Zero Day Initiative
Impact        critical
Description
An attacker was able to perform an out-of-bounds read or write on a
JavaScript object by fooling range-based bounds check elimination.

References    Bug 1886849

# CVE-2024-29944: Privileged JavaScript Execution via Event Handlers

Reporter      Manfred Paul via Trend Micro's Zero Day Initiative
Impact        critical
Description
An attacker was able to inject an event handler into a privileged object
that would allow arbitrary JavaScript execution in the parent process.
Note: This vulnerability affects Desktop Firefox only, it does not
affect mobile versions of Firefox.

References    Bug 1886852

There's a third-party write-up by @maxpl0it on the first bug above here:

https://twitter.com/maxpl0it/status/1771258714541978060

@_manfp's Firefox renderer bug is a beauty that takes advantage of an
optimisation implemented just 3 months ago. Let's break it down!

In JavaScript, you can get a list of property names of an object using
Object.keys(o). A common pattern to count the number of properties an
object has is to use Object.keys(o).length.

Now, this can actually end up being quite slow for large objects, since
Object.keys(o) constructs a whole new array with the property names in it.

If we're just interested in the length of this array and not the array
itself, this means we're spending considerable time constructing arrays
when we don't need to.

Thankfully, 3 months ago, Mozilla added a nice optimisation that means
the pattern of Object.keys(o).length no longer creates this array,
saving us from wasting a LOT of memory.
https://github.com/mozilla/gecko-dev/commit/eec1c03d31ad59280f99e9eafcd0eeb10e6a1ed5

So where's the bug? In the Range Analysis part of the just-in-time
compiler! The range that was given to the new MObjectKeysLength JIT node
was between 0 and NativeObject::MAX_SLOTS_COUNT, which is (1 &lt;&lt; 28) - 1.
However, the number of properties we can add is much larger.

Here is a test case that shows this behaviour. The returned value should
never be larger than (1 &lt;&lt; 28) - 1, which is 268435455. The trigger
shows that we can in fact go larger than this, a value that is not taken
into account by the range analysis.

This can lead to an incorrect elimination of a bounds check for an array
access and therefore an out-of-bounds read and write primitive.
Definitely one of the neatest Firefox bugs I've seen in a while!

The Twitter thread above includes some screenshots, which I did not
include here.  They're helpful, but not essential for understanding.

Alexander

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->

<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->

By Date

By Thread

Current thread:

Firefox 124.0.1 fixes two critical JavaScript engine vulnerabilities Solar Designer (Mar 23)

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->