Closed Bug 347580 Opened 18 years ago Closed 2 years ago

[meta] MathML Element and Attribute fuzzer


(Core :: Fuzzing, defect)

Not set





(Reporter: jruderman, Unassigned)


(Depends on 11 open bugs)


(Keywords: meta, sec-other, Whiteboard: [sg:nse] meta)


(1 file, 2 obsolete files)

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.)
Group: security
Whiteboard: [sg:nse] meta
Requires fuzz.js from bug 339948.
Attached file example test page
Depends on: 348492
Depends on: 348805
Depends on: 348811
>* 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 }
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=''>
  <annotation-xml encoding='MathML-Content'>

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 uses it in all their documents.)

<math xmlns=''>
  <annotation-xml encoding='MathML-Content'>
     <cn type='integer'>2</cn>
Depends on: 353612
Depends on: 354766
Attachment #232388 - Attachment is obsolete: true
Shouldn't have security bugs assigned to nobody. Jesse can own his test bugs
Assignee: nobody → jruderman
Depends on: 364685
Depends on: 364686
Depends on: 367107
Depends on: 368430
Depends on: 368461
Depends on: 370692
Depends on: 370884
Comment on attachment 242978 [details]
MathML Element and Attribute fuzzer 3.0

New version in bug 339948.
Attachment #242978 - Attachment is obsolete: true
Depends on: 372483
Depends on: 373472
Depends on: 375775
Depends on: 377824
Depends on: 378146
Depends on: 382208
Depends on: 382396
Depends on: 386010
Depends on: 391052
Depends on: 391747
Depends on: 393760
Depends on: 394150
Depends on: 395450
Depends on: 395556
Depends on: 395575
Depends on: 398038
Depends on: 398042
Depends on: 398510
Depends on: 399676
Depends on: 399940
Depends on: 399946
Depends on: 400057
Depends on: 400445
Depends on: 400475
Depends on: 400904
Depends on: 401589
Depends on: 403156
Depends on: 403310
Depends on: 403559
Depends on: 404485
Depends on: 405187
Depends on: 405271
Depends on: 411603
Depends on: 412237
Depends on: 413185
can't access bug 413185..
Depends on: 413274
Depends on: 415818
Depends on: 418007
Depends on: 420420
Depends on: 420654
Depends on: 429088
Depends on: 431072
Depends on: 433646
Depends on: 437142
Depends on: 437328
Depends on: 443089
Depends on: 450319
Depends on: 452150
Depends on: 454736
Depends on: 459883
Depends on: 460349
Depends on: 462929
Depends on: 464374
Depends on: 472587
Depends on: 473278
Depends on: 474377
Depends on: CVE-2010-3174
Depends on: 477294
Depends on: 477569
Depends on: 477740
Depends on: 494283
Depends on: 494300
Depends on: 507565
Depends on: 512304
Depends on: 512851
Depends on: 513378
Depends on: 523460
Depends on: 534366
Depends on: 538082
Depends on: 538207
Depends on: 539613
Depends on: 541620
Depends on: 544453
Depends on: 569018
Depends on: 573127
Depends on: 585745
Depends on: 594654
Depends on: 624198
Depends on: 630786
Depends on: 637242
Depends on: 657041
Depends on: 682646
Depends on: 686193
Depends on: 690247
Depends on: 713606
Depends on: 722022
Depends on: 736227
Depends on: 738190
Depends on: 766399
Depends on: 770710
Depends on: 772306
Depends on: 773941
Depends on: 784905
Depends on: 798534
Depends on: 804089
Depends on: 868907
Depends on: 1140268
No longer blocks: fuzz
Depends on: 1258076
Depends on: 1281714
Depends on: 1282637
Component: Tracking → Platform Fuzzing Team

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

Flags: needinfo?(jschwartzentruber)
Summary: MathML Element and Attribute fuzzer → [meta] MathML Element and Attribute fuzzer

(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.

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

Flags: needinfo?(jschwartzentruber)

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.

Assignee: jruderman → nobody
Flags: needinfo?(choller)
Closed: 2 years ago
Flags: needinfo?(choller)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.