Ref_fuzz and cross_fuzz are a pair of fuzzers developed in my spare time to 
stress-test DOM bindings in popular browsers. Both of these tools turned out 
to be dead effective against WebKit, Firefox, and Opera. 

With Internet Explorer, they were hitting comparatively fewer crashes, most 
of them NULL pointers; as a goodwill gesture, I have contacted MSRC to give 
them an opportunity to use the fuzzer in a parallelized setting if they are 
inclined to do so. This happened well in advance of the planned publication.

Here is a reasonably accurate account of our communications regarding these
tools; I am hoping that the timeline casts some light on my decision to go
public with cross_fuzz at this point (ref_fuzz is already public).

== Historical interest: ref_fuzz (2008-2010) ==

1) May 20, 2008: original report to MSRC. I note that the fuzzer is 
   triggering a number of crashes fairly quickly; most of these seem 
   non-exploitable. I suggest they may want to run the fuzzer more
   extensively, as all other browsers are affected badly. Report acknowledged
   (case 8246jr).

2) July 17, 2008: case closed - MSRC is unable to reproduce any exploitable 
   conditions, and will not be tracking the report. I do not investigate at 
   this point, working with other browser vendors instead.

3) September 23, 2009: after multiple delays at the request of other vendors, 
   I get close to the planned release of the tool. I re-test MSIE with a 
   slightly improved variant of the fuzzer - and immediately note that there
   are several seemingly exploitable crashes still reproducing for me. I 
   suspect these would have been discoverable with the original variant,
   although with a lower success ratio. MSRC pinged, cases opened (9480jr,
   9500jr, 9501jr).

4) October 14, 2009: MSRC finally confirms finding three underlying, 
   exploitable issues, working to fix them.

5) December 14, 2009: issues 9480jr and 9501jr are, quote, "unintentionally"
   patched without attribution in the December cummulative security update.
   MSRC apologizes, offers to revise the bulletin to add credit; this is
   ultimately not done.

6) January 27, 2010: case closed - MSRC does not see any more crashes.

7) March 10, 2010: I once again prepare for public release, re-test briefly;
   I note that there are still obvious, likely exploitable crashes, and
   I provide stack traces. Case reopened (9500jr).

8) June 8, 2010: The underlying memory corruption issue fixed, with 
   attribution (CVE-2010-1259).

9) June 8, 2010: Vendor-blessed public release of ref_fuzz.

A higher-level analysis of multi-vendor response in this case is given here:
http://lcamtuf.blogspot.com/2010/06/announcing-reffuzz-2yo-fuzzer.html

== Current: cross_fuzz (2010-2011) ==

1) July 26, 2010: original report to MSRC, noting multiple crashes and GDI 
   corruption issues. Acknowledged, case 10205jr.

2) July 29, 2010: updated version of the fuzzer sent, noting additional 
   problems. Acknowledged.

3) August 5, 2010: MSRC asks for OS and browser details. Info provided.

4) December 20, 2010: no further contact from MSRC up to this date. I
   ping them, noting the plan to release the tool early January.

5) December 21, 2010: response states that MSRC started composing a
   response, but never sent it out; and that the team had done some work
   in August, but could not reproduce anything interesting.

6) December 21, 2010: I note that I am still seeing scary crashes with the 
   fuzzer provided on July 29. I provide stack traces from a fresh install of 
   Windows with no plugins for one of the obviously exploitable vectors 
   (http://lcamtuf.coredump.cx/cross_fuzz/msie_crash.txt). I reiterate my plan 
   to release the tool in January.

7) December 21, 2010: David Ross confirms being able to reproduce crashes 
   locally right away.

8) December 22, 2010: MSRC reaches out, schedules a phone call. I reiterate 
   by mail that I plan to release in January.

9) December 28, 2010: I have a conference call with MSRC. The team expresses 
   concern over PR impact, suggests that the changes made to my fuzzer code 
   between July and December might have uncovered additional issues, which
   would explain why they were unable to reproduce them earlier.

   One of the potential reasons given is the change from Math.random() PRNG to
   Mersenne twister. I agree to postpone disclosure if this is the case.

10) December 28, 2010: I investigate code changes between July and December, 
    and conclude they are unlikely to have a substantial effect. I confirm this 
    by re-running the July 29 fuzzer and hitting the same condition as listed 
    in #5. I notify MSRC and reaffirm my plan to release in the first week of
    January.

11) December 29, 2010: Response from MSRC confirms that these crashes are
    reproductible with the July 29 fuzzer; unclear why they were unable
    to replicate them earlier, or follow up on the case:

    "Dave ran cross_fuzz_randomized_20100729.html last night and was able to
    hit a crash too. The IE team did exhaustively run the fuzzers but were
    unable to find the same crashes that you and Dave are now able to identify.
    I can't really say as to why we are able to hit some of these conditions
    now rather than before but please know that this was not intentional".

12) January 1, 2011: Public release of cross_fuzz.

For an additional reason why expedited release appeared prudent, see:
http://lcamtuf.coredump.cx/cross_fuzz/known_vuln.txt

*** UPDATE ***

Despite the contradictory quote in #11 and the easily verifiable analysis
outlined in #10, the current PR messaging from Microsoft implies that 
substantial differences existed between July and December fuzzer variants, 
and that the July 29 fuzzer could not reproduce the vulnerability outlined
in msie_crash.txt. This is inconsistent with my record.