1914521 - (CVE-2024-10461) XSS due to Content-Disposition being ignored in multipart/x-mixed-replace response

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect, P2)

Description

[Masato Kinugawa]

Attachment: fx_x-mixed-replace_content-disposition.php

In the multipart/x-mixed-replace response, Content-Disposition: attachment sent in the original response header is not respected and does not force a download. e.g.:

HTTP/1.1 200 OK
Date: Fri, 23 Aug 2024 00:14:12 GMT
Server: Apache
Content-Disposition: attachment    <--------------   This is ignored
Content-Length: 92
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: multipart/x-mixed-replace;boundary=BOUNDARY 

foo
--BOUNDARY
Content-Type: text/html

<script>alert(document.domain)</script>
--BOUNDARY--

This is not good because it is common for web apps to host user-uploaded files with user-specified MIME type and Content-Disposition: attachment header. Normally, the download is forced by the Content-Disposition: attachment header, so XSS does not occur no matter what Content-Type response header is used. However, in Firefox, since the Content-Disposition header is not respected when Content-Type: multipart/x-mixed-replace is used, XSS could occur. I have actually confirmed that multiple apps' file hosting feature is affected by this issue.

Steps to reproduce:

1. Open https://vulnerabledoma.in/fx_x-mixed-replace_content-disposition.php with Firefox.
2. Confirm that JavaScript is exeucted even though the original response header includes Content-Disposition: attachment.

I attached the PHP script used in PoC above.

Comment 1

[Masato Kinugawa]

Attachment: fx_x-mixed-replace_popupblockerbypass.php

FYI, there also seems to be a popup blocker bypass bug when handling a response including Content-Disposition: attachment + multipart/x-mixed-replace.

It can be reproduced just by opening this link: https://vulnerabledoma.in/fx_x-mixed-replace_popupblockerbypass.php
I attached the same PHP script here.

Comment 2

[Daniel Veditz [:dveditz]]

Similar, but less severe, CSP issue in bug 1864434 (at least the extra CSP headers are additive, not replaced).

Comment 3

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1914521 - Make nsPartChannel inherit the content disposition of the multipart response r=#necko

Comment 4

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1914521 - test that the multipart response content disposition overrides the one of the part r=#necko

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f2be5e2dc764
Make nsPartChannel inherit the content disposition of the multipart response r=necko-reviewers,jesup

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/f2be5e2dc764

We'll want uplift requests for Beta and ESR128 also when you've got a chance.

Comment 7

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1914521 - Make nsPartChannel inherit the content disposition of the multipart response r=#necko

Original Revision: https://phabricator.services.mozilla.com/D223728

Comment 8

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: Potentially XSS due to wrong content disposition for multipart channel
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: see comment 0
• Risk associated with taking this patch: low
• Explanation of risk level: The patch overwrites the part channel's content disposition with the root channel's one.
• String changes made/needed: none
• Is Android affected?: yes

Comment 9

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/3e6fea249806

Comment 10

[Bianca Hidecuti, Desktop Test Engineering [:bhidecuti]]

I was able to reproduce the issue on an affected Firefox 131.0b6 build, using macOS 14.6, while following the steps from Comment 0. When accessing https://vulnerabledoma.in/fx_x-mixed-replace_content-disposition.php the code is executed within the browser (a popup alert is displayed).
Verified as fixed with Firefox Nightly 133.0a1 (2024-10-03) and with Firefox 132.0b2, using macOS 14.6, Windows 11 and Ubuntu 22.04.
The browser prompts to download the file when opening https://vulnerabledoma.in/fx_x-mixed-replace_content-disposition.php.

Also, when navigating to https://vulnerabledoma.in/fx_x-mixed-replace_popupblockerbypass.php (see Comment 1), a download is triggered as well.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9428449 [details]
Bug 1914521 - Make nsPartChannel inherit the content disposition of the multipart response r=#necko

Approved for 128.4esr.

Comment 12

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/2f331426fe0d

Comment 13

[Daniel Veditz [:dveditz]]

Thankfully there's no file extension that I'm aware of that servers are set up to serve as x-multipart-replace, so it seems unlikely that a server would send that content-type with a user-uploaded filed.``

Comment 14

[Daniel Veditz [:dveditz]]

Of course, bugzilla attachments let people specify the content-type header :-)

Comment 15

[Bianca Hidecuti, Desktop Test Engineering [:bhidecuti]]

Verified as fixed on Firefox 128.4.0esr using Windows 11, macOS 14.7 and Ubuntu 22.04 as well.

Comment 16

[Jesse Schwartzentruber (:truber)]

Attachment: advisory.txt

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b9c6b2154f26
test that the multipart response content disposition overrides the one of the part r=necko-reviewers,jesup

Comment 18

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/b9c6b2154f26