1717560 - Changing a MathML (application/mathml+xml) file XML namespace lead to potential XSS vectors

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, task, P3)

Description

[Daniel Santos]

Overview
Firefox version 89.01 renders MathML documents (application/mathml+xml) as XHTML if the root node xmlns attribute is set to http://www.w3.org/1999/xhtml. This may allow an attacker to bypass blacklist-based upload filters, and, in specific cases, lead to cross-site-scripting (XSS).

Technical details
Firefox version 89.01 renders MathML documents (application/mathml+xml) according to the markup language specification. MathML's href attribute supports javascript URLs and may be used to exploit XSS vulnerabilities, however, they require user interaction. The following MathML document will contain a link to a javascript URL. When clicked, the link will execute the alert function.

<math xmlns="http://www.w3.org/1998/Math/MathML" href="javascript:alert(location)">
XSS
</math>

This is a known security issue when an application needs to handle inline MathML content.

A not-so-common scenario, which seems to affect Firefox only, is when a .mml is served by a web application. In that case, if no content-type is provided by the web server and content sniffing is allowed, or if the application/mathml+xml content-type is assigned to the file by the web server, Firefox will parse and render the .mml files as MathML documents. This may allow an attacker to bypass black-list-based upload filters and provide them with a Firefox-specific XSS vector. It is worth mentioning that neither Google Chrome nor Microsoft Edge behaves the same way. Both will display the .mml file contents as plain-text, even when the application/mathml+xml content-type is assigned to the file by the webserver. Moreover, specifying a different XML namespace to the .mml file root node allows an attacker to potentially exploit XSS vulnerabilities without requiring user interactions, therefore, increasing the vulnerability risk score. The following MathML document can be used as a proof-of-concept (POC)

<math xmlns="http://www.w3.org/1999/xhtml">
<script>
alert(1);
</script>
</math>

Recommendation
MathML (.mml) files should only be rendered according to the http://www.w3.org/1998/Math/MathML XML namespace to avoid XSS attacks without user interaction. As a suggestion, parsing/rendering .mml files could be made a non-default behavior controlled by a user-configurable parameter.

Comment 1

[Daniel Santos]

This is an example of a vulnerability https://hackerone.com/reports/429873 that only affects FF users because of the what is reported here.

Comment 2

[Andrew McCreight [:mccr8]]

Gijs, any ideas on what to do with this? Maybe this is due to something in nsExternalHelperAppService.cpp?

Comment 3

[:Gijs (he/him)]

(In reply to Andrew McCreight [:mccr8] from comment #2)

Gijs, any ideas on what to do with this? Maybe this is due to something in nsExternalHelperAppService.cpp?

I doubt it, but it's really not clear...

(In reply to Daniel Santos from comment #0)

Overview
Firefox version 89.01 renders MathML documents (application/mathml+xml) as XHTML if the root node xmlns attribute is set to http://www.w3.org/1999/xhtml.

This is kind of a strange description. I don't know what the current (non-1999) spec is for how browsers should deal with XML where the mimetype and contents are mismatched, and/or how XHTML with a non-html root node should behave (as that's what seems to be happening in the example you give at the bottom of comment 0), but it seems to me there should be a clear answer from the specs about what the right behaviour should be, and browsers should align on it, and it has nothing to do with mimetype sniffing / file handling - it's purely a parsing and/or DOM issue. Anne, do you know what defines how this is supposed to behave, and/or why other browsers have different behaviour?

Reporter: does the same problem not appear with SVG, image/svg+xml, or any other XML dialects?

A not-so-common scenario, which seems to affect Firefox only, is when a .mml is served by a web application. In that case, if no content-type is provided by the web server and content sniffing is allowed, or if the application/mathml+xml content-type is assigned to the file by the web server, Firefox will parse and render the .mml files as MathML documents.

Can you provide a live proof of concept, ie a web address that behaves in the way you believe is exploitable/problematic (or more than one of these, if there is more than 1 case that is problematic) ?

As it is, I can't tell if we're talking about content that renders immediately, if Firefox prompts asking what to do with a download, if the server sends a Content-Disposition: attachment header, any anti-mime-sniffing headers (like X-Content-Type-Options: nosniff), or why the mime sniffing code would determine that the result should be rendered via the DOM instead of downloaded (which quite possibly depends on the precise content of the file that is served).

This may allow an attacker to bypass black-list-based upload filters and provide them with a Firefox-specific XSS vector.

If there isn't a safelist of accepted mimetypes for upload, then the web server should not regurgitate user/attacker-provided input without sending Content-Disposition: attachment headers; where it doesn't send such headers, it should override mimetypes and prevent sniffing, in which case this problem shouldn't happen...

It is worth mentioning that neither Google Chrome nor Microsoft Edge behaves the same way. Both will display the .mml file contents as plain-text, even when the application/mathml+xml content-type is assigned to the file by the webserver.

Again, this really needs a more detailed PoC to be actionable. As it is I have no idea how this mml file is being served and what issues you're seeing.

Comment 4

[Daniel Santos]

(In reply to :Gijs (he/him) from comment #3)
I think the problem resides in the developer's expectations. The Ruby on Rails project, for example, keeps a list of mime-types for which the Content-Disposition: attachment header is forced when its Active Storage feature is used for file upload/serving (https://github.com/rails/rails/blob/main/activestorage/lib/active_storage/engine.rb#L54). It's just not expected that an attacker can get script execution through an mml or rdf file.

I believe the problem exists here https://searchfox.org/mozilla-central/source/parser/htmlparser/CParserContext.cpp#47 and it's broader than I thought. Any of the listed formats will be handled through a loose XML parser that allows the http://www.w3.org/1999/xhtml namespace to be used and script execution to be possible. When hosted in a standard Apache 2 web server as xss.rdf, the following file will trigger an alert.

<math xmlns="http://www.w3.org/1999/xhtml">
<script>
alert(1);
</script>
</math>

I will work on a more elaborate PoC and compare FF behavior with its direct competitors.

Comment 5

[Anne (:annevk)]

I think as far as security issues go this is INVALID as the HTML Standard has codified this behavior for well over a decade.

Comment 0 boils down to data:application/mathml+xml,<script xmlns="http://www.w3.org/1999/xhtml">alert(1)</script> and I do not recall anyone ever suggesting that should not execute script.

The one wrinkle here is that we never fixed bug 155730 and neither have other browsers. So while we support application/mathml+xml, other browsers do not, and none of us support application/custom+xml and many other +xml friends. We could at this point decide that perhaps it's no longer worth it to pursue that, drop the XML MIME types other browsers do not support (so they cause a download), and try get the HTML Standard changed to specify a more limited subset and converge on that.

But even something simple like data:application/atom+xml,<script xmlns="http://www.w3.org/1999/xhtml">alert(1)</script> executes script in all browsers so I think this really is a bug in applications that expect XML to not be able to execute script. And I think we should fix bug 155730 to drive that point home.

Comment 6

[Daniel Santos]

(In reply to Anne (:annevk) from comment #5)
Just one comment. Navigating to data:application/atom+xml,<script xmlns="http://www.w3.org/1999/xhtml">alert(1)</script> also have different behaviours depending on the browser used. Chrome will execute the script where FF will trigger a download.

I can agree this is not a security vulnerability in itself, but this lack of standardization surely confuses developers and may lead to vulnerabilities as a result.

Comment 7

[Anne (:annevk)]

Oh, I overlooked that somehow. But to be clear, this is standardized and has been for a long time: https://html.spec.whatwg.org/multipage/browsing-the-web.html#navigating-across-documents:xml-mime-type. The problem here is that there is a lack of interoperability with regards to the standard and I agree that may result in confusion and even security issues. However, I don't think the security issues are the responsibility of the browser in this case. It might be worth it to file an issue against the HTML Standard at https://github.com/whatwg/html/issues/new to see if these attacks can motivate folks to improve interoperability here, one way or another.

Comment 9

[:Gijs (he/him)]

(In reply to Anne (:annevk) from comment #7)

It might be worth it to file an issue against the HTML Standard at https://github.com/whatwg/html/issues/new to see if these attacks can motivate folks to improve interoperability here, one way or another.

We've had a dupe reported against Firefox for doing this for RDF and MathML. Do you know if a spec bug has been reported and/or fixed here yet? If not, should we open one ourselves at this point?

Comment 10

[Anne (:annevk)]

I filed an issue to track this and put it on the agenda. My tentative suggestion is that all browsers attempt to align with the HTML standard here. Open to other suggestions.