RE: Is MathML really Dangerous?

As Neil points out here, there are two kinds of security issue with respect to MathML: MathML instance security and MathML implementation security. The former has to do with the potential for <maction> and such to be used in malicious ways. This should be a concern for the Wikipedia folk assuming they allow authors to insert arbitrary valid MathML. MathML implementation security is more about things like does the implementation allow buffer overrun exploits.

The Chrome team was likely talking about implementation security but I don’t know for sure. I don’t know that they even found a potential security problem. I think they said that they couldn’t determine that the code was secure so it had to be removed. My guess is that they either didn’t have a volunteer, didn’t think the volunteer had the technical chops, were unwilling to pay the volunteer what they were asking to do the work, or simply don’t care enough about MathML to even think about it.

Paul

From: Neil Soiffer [mailto:NeilS@dessci.com]
Sent: Friday, December 04, 2015 2:53 PM
To: Paul Libbrecht <paul@hoplahup.net>
Cc: Physikerwelt <wiki@physikerwelt.de>; www-math@w3.org
Subject: Re: Is MathML really Dangerous?

MathML is a spec, not an implementation. The main security issues arise due to the implementations. It is sort of like asking, "is HTML safe"? There are some potential security vulnerabilities in the HTML spec due to links, etc, but the main security issues depend on the implementation. Is Chrome safe? Safrari? Firefox? IE? Given that they keep putting out security patches, the answer is almost certainly "none is 100% safe."

As Paul Topping noted, the Chrome team found a potential security problem in the MathML implementation (in WebKit) and yanked MathML. Safari just fixed the problem and kept MathML in their browser. It had nothing to do with a vulnerability in the spec, it was an implementation detail.
Paul Libbrecht already noted that appendix B of the spec (http://www.w3.org/TR/MathML3/appendixb.html) lists some potential vulnerabilities. These really don't differ from HTML vulnerabilities with the exception that doing a computation with them exposes you to the vulnerabilities of the computation system you use.

Neil Soiffer
Senior Scientist
Design Science, Inc.
www.dessci.com<http://www.dessci.com>
~ Makers of MathType, MathFlow, MathPlayer, MathDaisy, Equation Editor ~


On Fri, Dec 4, 2015 at 2:04 PM, Paul Libbrecht <paul@hoplahup.net<mailto:paul@hoplahup.net>> wrote:
Moritz,

Can an answer be read from the Media-Type registration's "Security Concerns":
    http://www.w3.org/TR/MathML3/appendixb.html


>From there, one can probably read what can be removed to make MathML safe:
- remove anything that includes external content (e.g. DTD things, styles, images, annotations),
- do not compute with it (or remove MathML-Content),
- remove foreign content (anything outside the MathML namespace and probably all annotations).

This has been validated by readers of the ietf-media-type mailing-list, I believe.

I'll note that the same requirement has been expressed for MathML to be considered by the ClipOps spec https://w3c.github.io/clipboard-apis/ which is still in draft.

Are we not able to write a note that demonstrates such a security?

Paul

Physikerwelt<mailto:wiki@physikerwelt.de>
4 décembre 2015 19:04
Dear W3C Math WG,

I wonder if there is a resilient security assessment for MathML. It
would be nice, if there was at least a subset of MathML, for which the
security was proven according to state-of-the-art of science and
technology. For example I could imagine that only presentation MathML
without a finite list of possible dangerous elements such as maction
or annotation could be the secure MathML subset.

The background of my question is that the Wikimedia Foundation
considers opening the POST endpoint for converting several input
formats (i.e. TeX, AsciMathML, and MathML) to MathML + SVG (+ PNG) [1]
for the public[2].
Currently this conversion endpoint it is only accessible from within
the Wikimedia Foundation cluster and only accepts texvc* input.

Best

Moritz Schubotz

[1] https://en.wikipedia.org/api/rest_v1/?doc#!/Math/post_media_math_check_type

if you try this link you’ll get a “This client is not allowed to use
the endpoint” exception rather than the security checked texvc output
you receive in the unstable demo here
http://math.beta.wmflabs.org:7231/math.beta.wmflabs.org/v1/?doc#!/Math/post_media_math_check_type


[2] https://phabricator.wikimedia.org/T116147


*) texvc is a well-defined subset of LaTeX with some custom macros.