ClusterFuzz is analyzing your testcase. Developers can follow the progress at https://cluster-fuzz.appspot.com/testcase?key=5339049884909568

This looks like a well-crafted exploit file. Am I correct in seeing that the target is Flash?

Yes. 

natashenka@: Can you please take a look?

This didn't crash in Clusterfuzz. 

The comments in the script make reference to heap corruption via nsCSSValue, and the archive contains a file named FF3.6.3-v2.0.js and a Heapspray applet in Java, leading me to believe that this code is a really 7 year-old repro file for a CVE in Firefox's CSS handling. 

rbcomic12@ can you please explain?

https://www.mozilla.org/en-US/security/advisories/mfsa2010-39/

Yes, this is actually the same report. I'm actually confused, Why the browsers can't handle the code and gets crashed..Although, this was reported to frefox long time back, Why they haven't fixed it? So I thought to share with you guys.

Assigning back to elawrence. It look like this bug isn't specific to Flash?

Re #8: Firefox fixed this bug in 2010, as noted in the link in #7. The bug relied upon a problem in handling of CSS arrays.

The vulnerable CSS codepath in question does not exist in Chrome. Additionally, Chrome does not support running Java (which was used in the proof-of-concept). 

The code will still hang the browser tab (as it allocates 100 Million array objects) but this does not represent a security bug (see e.g. https://dev.chromium.org/Home/chromium-security/security-faq#TOC-Are-denial-of-service-issues-considered-security-bugs- ).

If you have evidence of "memory corruption" or anything beyond the simple "safely crashed tab", please do update this issue.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot