MathML maction statusline - status bar text doesn't accurately reflect the target of the link

UNCONFIRMED
Unassigned

Status

()

Core
MathML
P3
normal
UNCONFIRMED
11 months ago
10 months ago

People

(Reporter: christopher.spaeth, Unassigned)

Tracking

54 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

11 months ago
Created attachment 8899449 [details]
mathml_csrf.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170628075643

Steps to reproduce:

1. Open attached file (locally or hosted on a webserver)
2. Hover over the fraction element
3. A innocuous looking link to https://www.w3.org/TR/MathML3/chapter3.html#presm.mfrac will be displayed on the statusline
4. If you click the link you will be redirected to attacker.org.







Actual results:

The statusline is overwritten by the mtext element.
This is mandated by the specification (https://www.w3.org/TR/MathML3/chapter3.html#presm.maction)
The executed action corresponds to the value of the href attribute. 

Since all MathML elements (Section 2.1.6) implement the "href" attribute, an attacker could craft a maction element with a href attribute leading to unwanted redirections, CSRF or JavaScript Execution in the context of the site with the user noticing afterwards!


Expected results:

In this specific instance users have no way of knowing where a given link redirects. 
Because of security considerations a "href" or xlink:href attribute  should therefore always take precedence to the value of "mtext".
(Reporter)

Comment 1

11 months ago
Created attachment 8899450 [details]
mathml_maction_js.html

Comment 2

11 months ago
This isn't "CSRF". CSRF is a web vulnerability where a website does not validate that a user actually intended to proceed with a given action adequately, such that clicking a link on some other website could execute actions that should be restricted (like deleting or editing information or whatever).

The only issue here is one of spoofing, that is, the website tries to mislead the user about where they are or where they are going. Unfortunately, in the face of JS, this isn't really a fixable problem. See also e.g. bug 229050 comment 27 and later.

In any case, this pretty clearly doesn't need to be hidden. I'll move it to mathml in case the mathml folks want to address the statusline thing separately (I kind of doubt it, but it's up to them).
Group: firefox-core-security
Component: Untriaged → MathML
Product: Firefox → Core
Summary: MathML maction statusline - security issue (CSRF, Script Execution) → MathML maction statusline - status bar text doesn't accurately reflect the target of the link
(Reporter)

Comment 3

11 months ago
Hi Gijs,
thanks for your reply.
I agree that this is not CSRF by itself - however it still holds true that by clicking a "deceptive" link this can be used for CSRF as this leads to executing an "unwanted action". 

I see your point with JavaScript as you elaborated in bug 229050 and I would like to add that MathML can be parsed only by an XML Parser (no XHTML and script execution) with the problem still being present.
Although this issue may be only an instance of a broader problem, fixing it will slightly increase security.

Thanks for your consideration. 
Chris
(Reporter)

Comment 4

11 months ago
just wanted to ask about the status here.

Comment 5

11 months ago
(In reply to christopher.spaeth from comment #4)
> just wanted to ask about the status here.

If there are updates, the bug will be updated. Mozilla doesn't have some kind of secret backend bugtracker where other work happens that we're not telling you about. Everything happens on this public bugtracker. If there are no updates on this bug, then there are simply no updates and asking isn't useful.

Right now there's no assignee, but the bug is in the right component, so hopefully people working on mathml will triage it and prioritize it appropriately.
As Gijs said, nobody is working on it, as indicated by the ASSIGNEE.

It's a known problem but I'm curious why it is so urgent for you? As you say this is really a edge case of a broader issue... do you have any concrete example in mind? AFAIK, MathML sanitizers remove the maction element to avoid that security issue.

I'm cc'ing more people who can give an opinion.
(Reporter)

Comment 7

11 months ago
I'm working as a researcher so I want to make sure that the problem is known to you before I will eventually publish it.

This problem might be known to people at Mozilla but I'm not sure about the other developers out there.
My impression is that few Sanitizers implement specific rules for MathML but rather rely on general detection mechanisms at the least.
I took a look at a few Sanitizers and WAFs and my evaluation suggests that this problem is not known, i.e. the vector passes through,for example, modsecurity with OWASP rules and RaptorWAF. 
For other Sanitizers it depends on the implementation of the whitelisted elements/attributes.

See here for a public available example, where it is not implemented correctly:
https://github.com/yesodweb/haskell-xss-sanitize/blob/master/Text/HTML/SanitizeXSS.hs

I would be interested, though, to know which MathML Sanitizers you have in mind.
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.