347580 - [meta] MathML Element and Attribute fuzzer

Status: RESOLVED FIXED

(Core :: Fuzzing, defect)

Description

[Jesse Ruderman]

This fuzzer:
* Creates most presentational MathML elements and attributes (but not content MathML).
* Avoids leaving elements with a fixed number of arguments invalid for long periods of time.
* Moves elements around (like Stir DOM)
* Sets display:none using CSS.

So far, I have found bug 347434, bug 347496, bug 347506, and bug 347507 with this fuzzer.  Most of these bugs involve MathML tables.

Testing with this fuzzer will become easier as those bugs, as well as some bugs found with Stir DOM (bug 347348, bug 347355, and bug 347495), are fixed.

I'd appreciate some hints to help me know what else to include:
* What content MathML elements does Gecko support? 
* What style rules does MathML support?  
(Note that the testcase in bug 325222 uses several features this fuzzer currently doesn't test.)

Comment 1

[Jesse Ruderman]

Attachment: MathML Element and Attribute fuzzer 2.0.6

Requires fuzz.js from bug 339948.

Comment 2

[Jesse Ruderman]

Attachment: example test page

Comment 3

[rbs]

>* What content MathML elements does Gecko support? 

None (natively). But actually, all of them through an (existing) XSLT stylesheet... [the so-called Universal MathML StyleSheet (UMSS) provided by W3C]. Because XSLT is built in Gecko and nothing else is required other than a <?xml> procesing instruction to reference the UMSS, it should be stressed therefore that Gecko can render Content Markup as well, if absolutely necessary, for those who insist on Content Markup, although scripting then becomes limited as is the case when XSLT is used in general. 

I have heard some commercial vendors claim in the marketing pitch of their own proprietary plug-in that Gecko doesn't support Content MathML. They don't mention the caveat that it is done with an existing XSLT stylesheet. Whereas in all fairness, there is a blatant difference with a standalone renderer that only does Presentation Markup and has no XSLT capability to build upon to provide Content Markup. (Like saying that Gecko doesn't support <marquee>, omitting to say that it is done via XBL.)

>* What style rules does MathML support?  

All MathML elements go through the Style System machinery and get styled in the cascade. No particular effort is made to short-circuit that. But only a few rules make sense in mathematical expressions -- particularly those related to fonts and colors. In fact, we are actually fighting to prevent some rules from applying to MathML... In particular, float: and position: are known to cause troubles (bug 322625). Anything inside <math> should ideally have float:none and position:static, but it is proving hard to enforce that without an expensive descendant rule: mathml|*, mathml|* *|* { float:none; position:static }

Comment 4

[rbs]

BTW, while on the topic of content markup, it is also worth nothing that it is possible to do dual markup (or parallel markup) -- where a formula is represented in _both_ presentation markup and content markup within the same <math>...</math>. This way, a renderer that only supports presentation will use the presentation section, while a computer algebra system that wants content markup for computations will use the content section. The syntax for parallel markup is like this:

<math xmlns='http://www.w3.org/1998/Math/MathML'>
 <semantics>
  ...presentation-markup-here...
  <annotation-xml encoding='MathML-Content'>
    ...content-markup-here...
  </annotation-xml>
 </semantics>
</math>

Gecko also supports this out-of-the box. For example, the following fragment renders directly as as x^2 + y in Gecko. (This means that in any case content markup is not a show-stopper for someone who really wants to have it in their documents. The large website http://www.cnx.org/content/browse_course_titles uses it in all their documents.)

<math xmlns='http://www.w3.org/1998/Math/MathML'>
 <semantics>
  <mrow>
   <msup>
    <mi>x</mi>
    <mn>2</mn>
   </msup>
   <mo>+</mo>
   <mi>y</mi>
  </mrow>
  <annotation-xml encoding='MathML-Content'>
   <apply>
    <plus/>
    <apply>
     <power/>
     <ci>x</ci>
     <cn type='integer'>2</cn>
    </apply>
    <ci>y</ci>
   </apply>
  </annotation-xml>
 </semantics>
</math>

Comment 5

[Jesse Ruderman]

Attachment: MathML Element and Attribute fuzzer 3.0

Comment 6

[Daniel Veditz [:dveditz]]

Shouldn't have security bugs assigned to nobody. Jesse can own his test bugs

Comment 7

[Jesse Ruderman]

Comment on attachment 242978 [details]
MathML Element and Attribute fuzzer 3.0

New version in bug 339948.

Comment 8

[Vlad Sukhoy]

can't access bug 413185..

Comment 9

[Jesse Ruderman]

https://github.com/MozillaSecurity/funfuzz/blob/master/dom/fuzzer/modules/generate-nodes-mathml.js

Comment 10

[Frederik Braun [:freddy]]

Do we still run MathML fuzzing? I'm asking because of all the MathML re-implementation that's currently happening.

Comment 11

[Frédéric Wang (:fredw)]

(In reply to Frederik Braun [:freddyb] from comment #10)

Do we still run MathML fuzzing? I'm asking because of all the MathML re-implementation that's currently happening.

I think bug 1583037 will be helpful here. Currently when an element does not have the expected number of children, we basically don't perform MathML layout in the subtree but just display an "invalid markup" message. That makes fuzzing and automatic testcase reduction harder.

Comment 12

[Jesse Schwartzentruber (:truber)]

Yes, we do. Domino (bug 1340565) is targeting MathML.

Comment 13

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

The bug assignee didn't login in Bugzilla in the last 7 months.
:decoder, could you have a look please?
For more information, please visit auto_nag documentation.