6 ms·

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.co

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 https://developers.google.com/v8/design#mach_code [1] http://www.webkit.org/blog/214/introducing-squirrelfish-extreme/ http://www.webkit.org/blog/214/introducing-squirrelfish-extr...

olliej 14y ago
I don't see why/where the code generator is involved here. The posted "exploit" doesn't appear to work at all, implying that either it's not complete (so discussing how it works is kind of pointless) or just bogus. 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.
Klinky 14y ago
Exploits have existed in web browsers since they were invented. Everything is eventually executed at some point, it really just depends on how good the thing doing the decoding/encoding is. Just because something is slow and seemingly encapsulated doesn't mean it is safer than running it lower to the metal. That's almost like security through obscurity, adding layers because you think it's safer, not because you know it is. Sometimes the layers are what make it more vulnerable, not less.

olliej 14y ago

I don't see why/where the code generator is involved here. The posted "exploit" doesn't appear to work at all, implying that either it's not complete (so discussing how it works is kind of pointless) or just bogus. 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.

Klinky 14y ago

Exploits have existed in web browsers since they were invented. Everything is eventually executed at some point, it really just depends on how good the thing doing the decoding/encoding is. Just because something is slow and seemingly encapsulated doesn't mean it is safer than running it lower to the metal. That's almost like security through obscurity, adding layers because you think it's safer, not because you know it is. Sometimes the layers are what make it more vulnerable, not less.