1546656 - mXSS via <math>

Status: REOPENED

(Core :: DOM: Serializers, defect, P3)

Description

Attachment: mXSS.html

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0

Steps to reproduce:

Hi some time ago i research security in web email applicatons and found bug in firefox.

The bug is similar then https://bugs.chromium.org/p/chromium/issues/detail?id=805924

How it can be used in email apps:
Vulnerable application inserts HTML code (that looks fine and bypass security filters) from API to page via innerHTML, then you can click button "print", or "open in new page" and now code from page inserts to new page via document.write.

Minimized proof in attachment.
Best regards!

Actual results:

FireFox incorectly renders tags after <math> braking.
FireFox decode attribute value from tags nested in <math> .

Expected results:

You can try this demo with other browsers:
https://html5sec.org/innerhtml/

HTML example:

<math>
	<ruby>
	<xmp>
		<img alt="&lt;/xmp&gt;<img src=s onerror=alert(1)>">
	</xmp>
</math>

Comment 1

[:Gijs (he/him)]

Henri, looks similar to bug 1528997 at a glance, but perhaps the root cause is different?

Comment 2

[Henri Sivonen (:hsivonen) (on vacation)]

(In reply to psych0tr1a from comment #0)

Vulnerable application inserts HTML code (that looks fine and bypass security filters)

The markup shown should not look fine to a competent security filter. A competent security filter

1. Parses the input using a spec-compliant HTML parser (that among other things, makes ruby break out of math per https://html.spec.whatwg.org/#parsing-main-inforeign ).
2. Drops everything that it doesn't know to be useful and safe for the use case. (At this point, it would drop the onerror attribute from the img element folowing the xmp element.)
3. Serializes the resulting document tree.

What kind of security filter do you believe the example to bypass and why would such a filter be appropriate to use?

You can try this demo with other browsers

AFAICT, the example given parses according to spec in Firefox, Chrome, and Safari.

Comment 3

[Henri Sivonen (:hsivonen) (on vacation)]

Sorry, Markdown broke the markup presented in comment 0, so I looked at the wrong markup.

Comment 4

[Henri Sivonen (:hsivonen) (on vacation)]

The attachment gets a spec-incompliant treatment in Chrome. It ignores the "If the parser was created as part of the HTML fragment parsing algorithm, then act as described in the "any other start tag" entry below. (fragment case)" part for ruby and lets ruby break out of math in the innerHTML setter.

Comment 5

[Henri Sivonen (:hsivonen) (on vacation)]

AFAICT, everything Firefox and EdgeHTML do here adheres to the spec. However, both Safari and Chrome have a bug in their innerHTML setter (in their implementation of the HTML fragment parsing algorithm).

It could be argued that the spec is dangerous due to parsing differing substantially between fragment and non-fragment modes, but a competent sanitizer, when operating in the fragment mode, should throw away ruby in the MathML namespace and xmp in the MathML namespace.

annevk, do you have opinions on whether to change the spec or to file bugs on Safari and Chrome?

Comment 6

[Henri Sivonen (:hsivonen) (on vacation)]

FWIW, the non-breakout in the fragment case is in the spec probably for two reasons:

1. To not accidentally break out of foreign content when setting innerHTML on an SVG or MathML node.
2. Because for the purpose of compat with legacy content the break-out is necessary only in non-fragment mode.

Comment 7

[psych0tr1a]

(In reply to Henri Sivonen (:hsivonen) from comment #2)

(In reply to psych0tr1a from comment #0)

Vulnerable application inserts HTML code (that looks fine and bypass security filters)

The markup shown should not look fine to a competent security filter. A competent security filter

1. Parses the input using a spec-compliant HTML parser (that among other things, makes ruby break out of math per https://html.spec.whatwg.org/#parsing-main-inforeign ).
2. Drops everything that it doesn't know to be useful and safe for the use case. (At this point, it would drop the onerror attribute from the img element folowing the xmp element.)
3. Serializes the resulting document tree.

What kind of security filter do you believe the example to bypass and why would such a filter be appropriate to use?

You can try this demo with other browsers

AFAICT, the example given parses according to spec in Firefox, Chrome, and Safari.

I can use more then 20 another tags then ruby
And noscript noframes noembed style instead xmp

Comment 8

[Henri Sivonen (:hsivonen) (on vacation)]

(In reply to psych0tr1a from comment #7)

I can use more then 20 another tags then ruby

The spec says "b", "big", "blockquote", "body", "br", "center", "code", "dd", "div", "dl", "dt", "em", "embed", "h1", "h2", "h3", "h4", "h5", "h6", "head", "hr", "i", "img", "li", "listing", "menu", "meta", "nobr", "ol", "p", "pre", "ruby", "s", "small", "span", "strong", "strike", "sub", "sup", "table", "tt", "u", "ul", "var" (plus special case for "font"), so this is expected.

And noscript noframes noembed style instead xmp

This is expected.

Comment 9

[Anne (:annevk)]

I'd start with filing a bug against Chrome and Safari. (It'd be somewhat interesting to know if when OP says they can use 20 other tags if those would also only be useful against Firefox or if those apply to Chrome and Safari too. I.e., how big is the mismatch with the standard?)

Comment 10

[Daniel Veditz [:dveditz]]

Chrome called their variant "Security_Severity-Low" so going with that. If we're going to argue about the spec that will be public, and the chrome bug is already, so might as well unhide this.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:hsinyi, could you have a look please?

For more information, please visit auto_nag documentation.