This is a personal blog. My other stuff: book | home page | Twitter | prepping | CNC robotics | electronics

January 01, 2011

Announcing cross_fuzz, a potential 0-day in circulation, and more

I am happy to announce the availability of cross_fuzz - a surprisingly effective but notoriously annoying cross-document DOM binding fuzzer that helped identify about one hundred bugs in all browsers on the market - many of said bugs exploitable - and is still finding more.

The fuzzer owes much of its efficiency to dynamically generating extremely long-winding sequences of DOM operations across multiple documents, inspecting returned objects, recursing into them, and creating circular node references that stress-test garbage collection mechanisms.

This design can make it unexpectedly difficult to get clean, deterministic repros; to that effect, in the current versions of all the affected browsers, we are still seeing a collection of elusive problems when running the tool - and some not-so-elusive ones. I believe that at this point, a broader community involvement may be instrumental to tracking down and resolving these bugs.

I also believe that at least one of the vulnerabilities discovered by cross_fuzz may be known to third parties - which makes getting this tool out a priority.

The following summarizes notification and patch status for all the affected vendors:

  • Internet Explorer: MSRC notified in July 2010. Fuzzer known to trigger several clearly exploitable crashes (example stack trace for CVE-2011-0346) and security-relevant GUI corruption issues (XP-only, example, CVE-2011-0347). >Reproducible, exploitable faults still present in current versions of the browser. I have reasons to believe that one of these vulnerabilities is known to third parties.

    Comment: Vendor has acknowledged receiving the report in July (case 10205jr), but has not contacted me again until my final ping in December. Following that contact attempt, they were able to quickly reproduce multiple exploitable crashes, and asked for the release of this tool to be postponed indefinitely. Since they have not provided a compelling explanation as to why these issues could not have been investigated earlier, I refused; see this timeline for more.

  • All WebKit browsers: WebKit project notified in July 2010. About two dozen crashes identified and addressed in bug 42959 and related efforts by several volunteers. Relevant patches generally released with attribution in security bulletins. Some extremely hard-to-debug memory corruption problems still occurring on trunk.

  • Firefox: Mozilla notified in July 2010. Around 10 crashes addressed in bug 581539, with attribution in security bulletins where appropriate. Fuzzing approach subsequently rolled into Jesse Ruderman's fuzzing infrastructure under bug 594645 in September; from that point on, 50 additional bugs identified (generally with no specific attribution at patch time). Several elusive crashes still occurring on trunk. Bad read / write offset crashes in npswf32.dll can also be observed if the plugin is installed.

  • Opera: vendor notified in July 2010. Update provided in December states that Opera 11 fixed all the frequent crashes, and that a proper security advisory will be released at a later date (release notes list a placeholder statement: "fixed a high severity issue"). Several tricky crashes reportedly still waiting to be resolved.

    Note that with Opera, the fuzzer needs to be restarted frequently.

Well, that's it. To download the tool or see it in action, you can follow this link. The fuzzer may be trivially extended to work with any other DOM-compliant documents, plugin bindings, and so forth.


  1. Thanks Michal. How hard would it be, and would there be any value in working this fuzzer into existing applications that may already be stressing the DOM?

  2. Larry: yes, it would be prudent to incorporate this with browser release QA test suites. My assumption is that at least some browser vendors will do so.

  3. When you release mangleme, you provided a mangle.cgi that logged, and a remangle.cgi that used the info in the log to reproduce the same page. You could do the same thing with this fuzzer, but the problem is where would you log? Filesystem access is restricted for obvious reasons. How about using document.cookie?

  4. Logging is a significant problem, yeah; but it's even mroe complicated: even if every eval() call is logged, this will not necessarily result in a case that can be minimized or even reproduces reliably. Note, for example, that the same initial random seed does not ilead to the same crash location.

  5. ""When you release mangleme, you provided a mangle.cgi that logged, and a remangle.cgi that used the info in the log to reproduce the same page. You could do the same thing with this fuzzer, but the problem is where would you log? Filesystem access is restricted for obvious reasons. How about using document.cookie?""

    What do you think about HTML5 localstorage (and WebSQL for IE)?

  6. What will happen on mobile browsers?

  7. Thany: Android and iPhone browsers are based on WebKit, and should share the same issues; similarly for Windows Mobile (a fork of IE).

    I haven't tested the fuzzer there, and there might be some hiccups (e.g., related to popup management), but in principle, it should be roughly the same thing.

  8. Johan: you can use these, although I don't think they offer strong guarantees of data integrity / completeness following a crash.

  9. Brilliant fuzzing approach :D Our brave new garbage-collected world needs to be stress tested this way more often! I'm betting Flash will be a source of problems for some time... How many systems have you tested on?


    I really like your idea of incorporating your fuzzer's techniques into projects' QA testing! To this end, do you have any advice for developers who are not working with web browsers, but who are employing their Javascript engines? (Spidermonkey, V8)

    Thanks for your hard work! I can imagine it's frustrating to chase such elusive crashes!

  10. Donny: the fuzzer can be probably easily adopted for non-browser uses (it has some dependence on window / document DOM, but not for the essential parts). In general, good test coverage + continuous fuzzing is a good idea.

  11. "I also believe that at least one of the vulnerabilities discovered by cross_fuzz may be known to third parties - which makes getting this tool out a priority."

    Hi, Michal - I am not sure I understand why a fuzzing tool is needed after a vuln is found. Am I missing something about a feature of the tool or a property of the vulns being found?


  12. Pete: the tool is needed to reproduce, investigate, and address vulnerabilities; beyond that, it serves no immediate purpose :-)

    In general, vendors had several months to investigate, and past a certain point, the benefits of keeping the broader community in the loop seem to outweigh the risks; doubly so if the tool happens to reproduce a vulnerability privately known to third parties with an uncertain agenda. I had several posts dissecting this topic in the past, e.g.:

    It's easy to frame the publication of this tool as controversial or damaging, but I do not think it is; because of the design of this tool, the expertise needed to actually go from it to a usable attack vector, to an exploit, is far higher than that needed to create a similar tool.

  13. I find it rather disconcerting that after a Firefox/Mac 4.0b7 crash by your tool, it now seems to operate hidden when I restart Firefox, without Firefox showing any window. Only some Find and Save dialogs popup every so often. Nothing in Exposé either.

    Not that this is a problem with your tool, just that a browser really shouldn't open after a fresh start to something hidden doing its nefarious things.

    I'll probably just purge my Firefox profile after I had enough of cross_fuzz, but case anyone likes to trace how this is happening just shoot me a message.

    - Henk Poley

  14. You probably have session restore configured, causing the browser to restart with the fuzzer whenever launched again. A very simple way to break this cycle would be to simply launch it while you are offline, and then close the offending tabs.

    The window being off-screen is a more serious problem (and a bug). I am not familiar with MacOS WM, but if there is a way to request the window to be maximized or otherwise moved to a more reasonable location, that may be useful. If not, I am not sure where the setting may be kept by Firefox or the WM. You can also try hitting the keyboard shortcut to open a new window (Ctrl-N?) and see if that helps.

  15. Cross fuzz? You mean an angry policeman? ;P

  16. Thanks for creating the tool and your patience with the M$ beast in releasing it. I doubt I would have waited for six months to release and M$ asking you to not release after ignoring your notification for over 5 months is reprehensible, but hardly surprising. For M$ this is business as usual. Funny to watch their PR machine go into overdrive, AGAIN, rather than just fixing the problem.

    Perhaps they really are as incompetent as many of us believe that they are as a company. For my part I stopped using their products over 4 years ago, except on select business contracts where we are given no choice but M$...ugh.

    Keep up the great work!

  17. I was wondering if Google Chrome was also affected by this vulnerability.

  18. Dan: Which vulnerability?

    The fuzzer triggered security-relevant problems in all browsers on the market, including all WebKit ones; WebKit is at the core of Chrome, Safari, Palm / iPhone / Android browsers, and more.

  19. Thank you. I learned about this from the website but I am surprised that cert has not mentioned in their vulnerability blog that the fuzzer triggered security-relevant problems affect numerous browsers and not just Internet Explorer.

  20. Tip for fuzzing IE: you can use Scripting.FileSystemObject in the local computer zone to write to text files.