[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    [oss-security] Firefox 124.0.1 fixes two critical JavaScript engine vulnerabilities
From:       Solar Designer <solar () openwall ! com>
Date:       2024-03-23 14:14:35
Message-ID: 20240323141435.GA24889 () openwall ! com
[Download RAW message or body]

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 << 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 << 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
[prev in list] [next in list] [prev in thread] [next in thread]