Nytro Posted March 8, 2013 Report Posted March 8, 2013 [h=2]lundi 25 février 2013, 17:26:37 (UTC+0100)[/h] [h=3]Mutation-based fuzzing of XSLT engines[/h] IntroI did in 2011 some research about vulnerabilities caused by the abuse of dangerous features provided by XSLT engines. This leads to a few vulnerabilities (mainly access to the file system or code execution) in Webkit, xmlsec, SharePoint, Liferay, MoinMoin, PostgreSQL, ... In 2012, I decided to look for memory corruption bugs and did some mutation-based (aka "dumb") fuzzing of XSLT engines. This article presents more than 10 different PoC affecting Firefox, Adobe Reader, Chrome, Internet Explorer and Intel SOA. Most of these bugs have been patched by their respective vendors. The goal of this blog-post is mainly to show to XML newbies what pathological XSLT looks like. Of course, exploit writers could find some useful information too.When fuzzing XSLT engines by providing malformed XSLT stylesheets, three distinct components (at least) are tested:- the XML parser itself, as a XSLT stylesheet is a XML document- the XSLT interpreter, which need to compile and execute the provided code- the XPath engine, because attributes like "match" and "select" use it to reference dataGiven that dumb fuzzing is used, the generation of test cases is quite simple. Radamsa generates packs of 100 stylesheets from a pool of 7000 grabbed here and there. A much improved version (using among others grammar-based generation) is on the way and already gives promising results ;-) PoC were minimized manually, given that the template structure and execution flow of XSLT doesn't work well with minimizers like tmin or delta.Intel SOA Expressway XSLT 2.0 ProcessorIntel was proposing an evaluation version of their XSLT 2.0 engine. It's quite rare to encounter a C-based XSLT engine supporting version 2.0, so it was added to the testbed even if it has minor real-world relevance. In my opinion, the first bug should have been detected during functionnal testing. When idiv (available in XPath 2.0) is used with 1 as the denominator, a optimization/shortcut is used. But it seems that someone has confused the address and the value of the corresponding numerator variable. Please note that the value of the numerator corresponds to 0x41424344 in hex.Articol:http://www.agarri.fr/blog/index.html Quote
