1955311 - (CVE-2026-4726) Additional security impact from expat CVE-2024-8176 / crashing other sites + whole browser

Status: RESOLVED FIXED

(Core :: XML, defect)

Description

[Hanno Boeck]

I had previously reported https://bugzilla.mozilla.org/show_bug.cgi?id=1954018 about expat CVE-2024-8176 that allows crashing a tab in Firefox. That bug is now public, therefore, I am reporting additional impact here in a separate bug, as I believe the security impact is significantly more severe than I initially thought.

It is possible not just to crash a tab when one controls the site displayed in the tab, but also via subresources like images (svg), iframes, or favicons (also svg). Each of them has different impacts:

• If one references a favicon with the CVE-2024-8176 proof of concept, this crashes not just the tab, but the whole browser. Apart from raising the impact of CVE-2024-8176, I also wonder if this points to a design flaw in Firefox' process/site isolation. If the favicon rendering is not guarded by the sandbox + site isolation, this seems concerning given the wide variety of image parsers available. Example: https://x.q2.re/exic.html

• An image tag referencing a file with the CVE-2024-8176 PoC and an svg extension and mime type will crash the whole tab. It is extremely common that sites allow embedding third-party images. A common case is, e.g., opengraph preview images that are often not re-encoded, but simply referenced from its original server. To illustrate what this means: Imagine a chat app supporting opengraph previews, and a large chatroom. By posting a link to an html file that references the PoC as an opengraph preview image, this can make the chatroom inaccessible for all Firefox users. Every attempt to load it will crash the Tab. (This works, e.g., in Mattermost and Rocket Chat, two very commonly used webchat solutions. It also works in some social networks, e.g. Xing.) Example for simple img tag: https://x.q2.re/eximg.html Example for opengraph: https://x.q2.re/exog.html

• An iframe will also crash the whole tab. This is, e.g., exploitable in social networks that allow embedding content in iframes. (It used to be possible on Twitter to embed external iframes for videos, I have not verified whether this is still the case.) This would allow, e.g., crashing other people's tab on a social media site by showing them a post. (I'm also surprised that this works and is not prevented by Firefox' site isolation.) Example: https://x.q2.re/exiframe.html

Comment 1

[Hanno Boeck]

Update: The third scenario (iframe) does not work like I thought. It appears the iframe will only crash the top frame if it's an iframe on the same host. A cross-site iframe will not crash the whole tab.

Comment 2

[Frederik Braun [:freddy]]

The fact that we load some images in the parent is indeed very unfortunate, but a known issue (e.g., bug 1586083).

Comment 3

[Andreas Farre [:farre]]

Freddy, can you assign a severity?

Comment 4

[Daniel Veditz [:dveditz]]

Adding a couple "see also" links:
A general "don't load favicons in parent" issue is bug 1586083 (as Freddy noted).
A more specific "favicons can easily crash the whole browser" issue—including an SVG expat-crash example—is bug 1863626

Loading the image in the parent violates the intention of our sandbox more than it does site isolation (that is, it's worse).

An iframe will also crash the whole tab. [...] (I'm also surprised that this works and is not prevented by Firefox' site isolation.) Example: https://x.q2.re/exiframe.html

The "tab" doesn't crash, the child process hosting that site's content crashes, taking down all of the same-site documents running in that process. Potentially lots of tabs could crash at once if they're all from the same site. In your example both the top-level document and the frame are same-origin, and we will always load a same-origin frame in the same process as its parent to reduce the need for IPC; not sure if that's always true for same-site frames. The SOP prevents direct DOM access so it may not have been as important, but if we can avoid launching a new process that's always a win.

As you discovered, if the framed content is cross-site then only the frame crashes and the user will see an infobar that says "part of the page" crashed. Example: copy the following and paste it into a new tab:
data:text/html,<body>hello<iframe src="https://x.q2.re/t1.xml"></iframe></body>

Comment 5

[Tom Schuster]

I think we can close this as fixed now, with both favicons not being rendered in the parent anymore and expat being updated.