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.

The cross_fuzz fuzzing Algorithm

1. Open two windows with documents of any (DOM-enabled) type. Simple HTML, XHTML, and SVG documents are randomly selected as targets by default – although any other, possibly plugin-supported formats could be targeted instead.
2. Crawl DOM hierarchy of the first document, collecting encountered object references for later reuse. Visited objects and collected references are tagged using an injected property to avoid infinite recursion; a secondary blacklist is used to prevent navigating away or descending into the master window. Critically, random shuffling and recursion fanout control are used to ensure good coverage.
3. Repeat DOM crawl, randomly tweaking encountered object properties by setting them to a one of the previously recorded references (or, with some probability, to one of a handful of hardcoded “interesting” values).
4. Repeat DOM crawl, randomly calling encountered object methods. Call parameters are synthesized using collected references and “interesting” values, as noted above. If a method returns an object, its output is subsequently crawled and tweaked in a similar manner.
5. Randomly destroy first document using one of the several possible methods, toggle garbage collection.
6. Perform the same set of crawl & tweak operations for the second document, but use references collected from the first document for overwriting properties and calling methods in the second one.
7. Randomly destroy document windows, carry over a percentage of collected references to the next fuzzing cycle.

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.

You can download cross_fuzz here:

http://lcamtuf.coredump.cx/cross_fuzz

Or read more here.

tl;dr version is something like this: Michal Zalewski writes a DOM fuzzer, fuzzes IE, finds flaws, Chinese dudes Google some .dll functions and find fuzzer results.

It could be some kind of weird coincidence, or you could read a whole conspiracy theory into it (unreleased tool, very specific search terms etc.).

Details concerning a potentially serious security vulnerability in fully patched versions of Microsoft’s Internet Explorer have been leaked to people in China, a researcher warned over the weekend.

Michal Zalewski, a security researcher at Google, blogged that data concerning at least one “clearly exploitable crash” in the Microsoft browser was inadvertently disclosed to people who were using a Chinese IP address. Details about the bug, which resides in the mshtml.dll component, were stored on a server that had accidentally been indexed by Google, Zalewski wrote elsewhere. On December 30, detailed search queries showed that the sensitive information, in addition to files for an unpublished security tool, had been retrieved by the unknown party.

“This pattern is very strongly indicative of an independent discovery of the same fault condition in MSIE by unrelated means,” Zalewski wrote. “Other explanations for this pair of consecutive searches seem extremely unlikely.”

The bug leads to arbitrary crashes in the EIP, or extended instruction pointer, of machines running the Microsoft browser. Zalewski said the flaw “is pretty much fully attacker-controlled.” It was uncovered using cross_fuzz, a security tool the researcher developed in his spare time more than two years ago to identify potential security vulnerabilities in IE, Firefox, and other browsers. Since its release, the tool has helped to identify nearly 100 various browser bugs.

You can find the complete history between MZ and Microsoft regarding both ref_fuzz and cross_fuzz here:

fuzzer_timeline.txt

As for the ‘discovery’ it does seem likely that someone else had already discovered the same vulnerability and were searching for further information about it and if it had been published/disclosed. The search logs are here:

known_vuln.txt

A statement attributed to Jerry Bryant, group manager in Microsoft’s Response Communications, said company researchers are working to reproduce the crash to see if the underlying vulnerability can be exploited by malicious hackers.

“At this point, we’re not aware of any exploits or attacks for the reported issue and are continuing to investigate and monitor the threat environment for any changes,” Bryant said.

Zalewski provided this account of his communications with Microsoft, which started in May 2008. In it, he claims that on December 21, Microsoft researcher David Ross “confirms being able to reproduce crashes locally right away.”

Zalewski said that Microsoft researchers asked him to delay the release of cross_fuzz until they had more time to investigate the crashes. He published his warning on New Year’s Day, after he learned that the crash logs and related files had been downloaded.

“These search queries are looking for information on two MSHTML.DLL functions – BreakAASpecial and BreakCircularMemoryReferences – that are unique to the stack signature of this vulnerability, and had *absolutely* no other mentions on the internet at that time,” he said.

cross_fuzz has been released officially now by Zalewski after Microsoft have had some time to investigate the crashes further. The moral of the story is, once again don’t use Internet Explorer!

As right now, there is a potentially dangerous 0-day for IE in the wild and as we well known with Patch Tuesday it’ll be quite some time before it gets fixed.

Source: The Register

A new tool dealing with web sessions was recently announced, it’s called stompy, a free tool to perform a fairly detailed black-box assessment of WWW session identifier generation algorithms. Session IDs are commonly used to track authenticated users, and as such, whenever they’re predictable or simply vulnerable to brute-force attacks, we do have a problem.

The tool has already revealed several problems in proprietary software platforms such as BEA WebLogic and Sun Java System Web Server (both have problems with their JSESSIONIDs).

Why bother?

Some session ID cookie generation mechanisms are well-studied and well-documented, and believed to be cryptographically secure (example: Apache Tomcat, PHP, ASP.NET builtins). This is not necessarily so for certain less researched enterprise web platforms – and almost never so for custom solutions that are frequently implemented inside the web application itself.

Yet, while there are several nice GUI-based tools designed to analyze HTTP cookies for common problems (Daves’ WebScarab, SPI Cookie Cruncher, Foundstone CookieDigger, etc), they all seem to rely on very trivial, if any, tests when it comes to unpredictability (“alphabet distribution” or “average bits changed” are top shelf); this functionality is often not better than a quick pen-and-paper analysis, and can’t be routinely used to tell a highly vulnerable linear congruent PRNG (rand()) from a well-implemented MD5 hash system (/dev/urandom).

What’s cool?

In order to have a fully automated, hands-off tool to reliably detect anomalies that are not readily apparent at a first glance stompy:

• Automatically finds session IDs encoded as URLs, cookies, and in form inputs, then collects a statistically significant sample of data
• Determines alphabet structure to transparently handle base64, uuencode, base32, hex, and any other sane encoding scheme without user intervention
• Translates the data to isolated time-domain bitstreams to examine how SID bits at each position change in time,
• Runs a suite of FIPS-140-2 PRNG evaluation tests on the sample
• Runs an array of n-dimensional phase space tests to find deterministic correlations, PRNG hyperplanes, etc, etc.

Of course, the tool cannot prove the correctness of an implementation, and it is possible to devise predictable, cryptographically unsafe PRNGs that would pass these tests; still, the tool can find plenty of problems and oddities.

Stompy was updated due to feedback and:

• It now supports SSL connections, custom-crafted requests including POSTs, and input from external sources (for evaluation of non-WWW tokens of any type)
• It now uses GNU MP library to losslessly handle alphabets that do not directly map to binary (this is big)
• Can run spatial correlation checks as well as temporal analysis of bitstreams in acquired samples
• The output is much more readable, some minor bugs were fixed.

The latest version of Stompy can be downloaded here:

http://lcamtuf.coredump.cx/stompy.tgz