[meta] MathML Element and Attribute fuzzer
Categories
(Core :: Fuzzing, defect)
Tracking
()
People
(Reporter: jruderman, Unassigned)
References
(Depends on 10 open bugs)
Details
(Keywords: meta, secother, Whiteboard: [sg:nse] meta)
Attachments
(1 file, 2 obsolete files)
11.63 KB,
application/xhtml+xml

Details 
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.)
Reporter  
Updated•18 years ago

Reporter  
Updated•18 years ago

Reporter  
Comment 2•18 years ago


>* What content MathML elements does Gecko support? None (natively). But actually, all of them through an (existing) XSLT stylesheet... [the socalled 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 plugin 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 shortcircuit 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='http://www.w3.org/1998/Math/MathML'> <semantics> ...presentationmarkuphere... <annotationxml encoding='MathMLContent'> ...contentmarkuphere... </annotationxml> </semantics> </math> Gecko also supports this outofthe 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 showstopper 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> <annotationxml encoding='MathMLContent'> <apply> <plus/> <apply> <power/> <ci>x</ci> <cn type='integer'>2</cn> </apply> <ci>y</ci> </apply> </annotationxml> </semantics> </math>
Comment 6•18 years ago


Shouldn't have security bugs assigned to nobody. Jesse can own his test bugs
Reporter  
Comment 7•18 years ago


Comment on attachment 242978 [details] MathML Element and Attribute fuzzer 3.0 New version in bug 339948.
Reporter  
Updated•16 years ago

Reporter  
Comment 9•9 years ago


https://github.com/MozillaSecurity/funfuzz/blob/master/dom/fuzzer/modules/generatenodesmathml.js
Updated•8 years ago

Comment 10•5 years ago


Do we still run MathML fuzzing? I'm asking because of all the MathML reimplementation that's currently happening.
Updated•5 years ago

Comment 11•5 years ago


(In reply to Frederik Braun [:freddyb] from comment #10)
Do we still run MathML fuzzing? I'm asking because of all the MathML reimplementation 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•5 years ago


Yes, we do. Domino (bug 1340565) is targeting MathML.
Comment 13•3 years ago


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.
Updated•3 years ago

Description
•