[<prev] [next>] [day] [month] [year] [list]
Date: Sat, 23 Mar 2024 15:14:35 +0100
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Firefox 124.0.1 fixes two critical JavaScript engine vulnerabilities
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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
