With V8[0] and Nitro[1] having gone mainstream, it has never been more easier for these kinds of exploits to exist on the Web.
[0] https://developers.google.com/v8/design#mach_code
[1] http://www.webkit.org/blog/214/introducing-squirrelfish-extr...
[0] https://developers.google.com/v8/design#mach_code
[1] http://www.webkit.org/blog/214/introducing-squirrelfish-extr...
There's nothing that I see that makes it obvious that it's attacking the JIT logic specifically. It's most reminiscent of the fairly old heap spray techniques which require an additional exploit anyway.
For instance the function for testing existence of the bogus microcode is: function test(result) { // giant comment explaining the asm used to test for the vulnerability unescape('%u31C9%u5589%uE55D%u2EF8%uC390%u9090'); return 0; }
Presumably the call to unescape is intended to convert the encoded shellcode into somthing useful. But there does not appear to be anything done to actually execute the shellcode. The historical way of doing this (blocked by DEP) is to fill the heap with copies of the string, and then use another exploit to jump into the heap at somewhere likely to contain your code. There are ways to bypass DEP, but this doesn't appear to try even that.
Honestly it looks like someone has simply taken the assembly used to the exploit, put it in a string (using numeric character escapes), and then done nothing else.
That it is referring to launching threads makes me wonder if this isn't just someone converting a pre-existing C program into something that at least parses as JS.