5 ms·

I think this comment comes the closest to the truth. The author responded to detractors on twitter by posting a link to the C proof-of-concept that he was appa

I think this comment comes the closest to the truth. The author responded to detractors on twitter by posting a link to the C proof-of-concept that he was apparently attempting to translate into javascript: http://pastebin.com/dHgn0fP7 http://pastebin.com/dHgn0fP7 The C source is definitely what the javascript is based off of, but the modifications (even if for "protection against lamers") are puzzling to say the least. Source: Author's twitter: http://twitter.com/sanjar_satsura http://twitter.com/sanjar_satsura

duskwuff 14y ago
Aha! The C PoC could possibly work, but the JS translation is hilariously amateurish. The author doesn't appear to have actually understood the code they were translating at all, and I'm pretty certain that it's actually impossible to run from JS anyway.
- jasonwatkinspdx 14y ago
  It may be possible, by exploiting bugs in the cache control logic of the processor. If there is a bug that is predictable enough to make a controlled redirection of a cache line write, it may not matter if the source of the contention is in non executable (data) memory. If all you need to do is get contention at some cache line in a certain way, you could probably do that with string processing code running in an interpreter. You'd need to overcome address space randomization but apparently there are reflection techniques that allow that to some extent. In any case, I'd wait for confirmation from a white hat researcher who knows their shit, but I wouldn't reject out of hand that this is possible from javascript. CPU logic exploits are quite a different beast from the more common buffer overflows or OS flaw exploits.
  - duskwuff 14y ago
    Hmm. Looking at the C exploit some more, it looks as though the exploit might be as simple as a very specific pattern of memory accesses from multiple threads, some of which are to code that's being executed. The memory access part is definitely doable from JS. Multiple threads is harder -- you might be able to do it by using web workers. Targeting memory access to a JIT-compiled function, however, would be the hard part; I don't see any way of doing that, short of executing the function (which would probably not have the desired effect).
    - jasonwatkinspdx 14y ago
      Again, I'm way out of depth here, but if your javascript loop ran fast enough relative to the cache latency, you could perhaps create a similar effect. The key would be whether the cache logic flaw depended on requests from two distinct cores to the same cache line, or if it's something that multiple requests from a single core can excite. No clue if this is the case.
ObnoxiousJul 14y ago
Hum .... Porting C to js... Are you serious? Where are your pointers, ASM registers in js? The claim you could inject arbitrary code from JS into your memory and make it executable from user space (not talking of the cross platform issue (BSD,linux, windows, MACOSX) would just be the end of JS. How can you even accept the claim that it can be doable. Be real. This news is like an april's fool in july. Use your brain.
- drewcrawford 14y ago
  Arguments from incredulity and personal insults have no place in reasoned discussion. > The claim you could inject arbitrary code from JS into your memory and make it executable from user space One of the dozens of ways that you would go about this is documented in some detail here: http://stackoverflow.com/questions/381171/help-me-understand-this-javascript-exploit http://stackoverflow.com/questions/381171/help-me-understand...
  - duskwuff 14y ago
    As Raymond Chen would put it, though, "that would involve being on the other side of this airtight hatchway"[1]. While it's occasionally possible to execute native code from Javascript due to browser bugs, such bugs are uncommon, and are in any case quite separate from the CPU bug that this exploit claims to target. [1]: http://blogs.msdn.com/b/oldnewthing/archive/2010/12/08/10101773.aspx http://blogs.msdn.com/b/oldnewthing/archive/2010/12/08/10101...
  - ObnoxiousJul 14y ago
    well, figure that if it were true, Java, python, Perl, c# are useless tools for delivering cross x86 OS code. (I just develop a side effect of the claim one can inject some code in memory bypassing all the HW/OS control). Why God these stupid Larry Wall, GvR, MS, Sun, Google, linus torvalds lost their time trying to achieve what a JS code can do in less than 1000 lines? How can I believe a code I can read and that is obviously a fraud would through the sheer power of obfuscated unused strings become such a revolution in the world of CS? Plus, I have no demonstration nor readable documents to back up the claims of this so called genius. Science is accepting what you can understand and reproduce. Not being impressed by obfuscated crap. I have no doubt this is a mystification, and I don't trust blindly what is written on the internet. I still have a brain.
Camillo 14y ago
And where is micro.dat?

duskwuff 14y ago

Aha! The C PoC could possibly work, but the JS translation is hilariously amateurish. The author doesn't appear to have actually understood the code they were translating at all, and I'm pretty certain that it's actually impossible to run from JS anyway.

jasonwatkinspdx 14y ago
It may be possible, by exploiting bugs in the cache control logic of the processor. If there is a bug that is predictable enough to make a controlled redirection of a cache line write, it may not matter if the source of the contention is in non executable (data) memory. If all you need to do is get contention at some cache line in a certain way, you could probably do that with string processing code running in an interpreter. You'd need to overcome address space randomization but apparently there are reflection techniques that allow that to some extent. In any case, I'd wait for confirmation from a white hat researcher who knows their shit, but I wouldn't reject out of hand that this is possible from javascript. CPU logic exploits are quite a different beast from the more common buffer overflows or OS flaw exploits.
- duskwuff 14y ago
  Hmm. Looking at the C exploit some more, it looks as though the exploit might be as simple as a very specific pattern of memory accesses from multiple threads, some of which are to code that's being executed. The memory access part is definitely doable from JS. Multiple threads is harder -- you might be able to do it by using web workers. Targeting memory access to a JIT-compiled function, however, would be the hard part; I don't see any way of doing that, short of executing the function (which would probably not have the desired effect).
  - jasonwatkinspdx 14y ago
    Again, I'm way out of depth here, but if your javascript loop ran fast enough relative to the cache latency, you could perhaps create a similar effect. The key would be whether the cache logic flaw depended on requests from two distinct cores to the same cache line, or if it's something that multiple requests from a single core can excite. No clue if this is the case.

ObnoxiousJul 14y ago

Hum .... Porting C to js... Are you serious? Where are your pointers, ASM registers in js? The claim you could inject arbitrary code from JS into your memory and make it executable from user space (not talking of the cross platform issue (BSD,linux, windows, MACOSX) would just be the end of JS. How can you even accept the claim that it can be doable. Be real. This news is like an april's fool in july. Use your brain.

drewcrawford 14y ago
Arguments from incredulity and personal insults have no place in reasoned discussion. > The claim you could inject arbitrary code from JS into your memory and make it executable from user space One of the dozens of ways that you would go about this is documented in some detail here: http://stackoverflow.com/questions/381171/help-me-understand-this-javascript-exploit http://stackoverflow.com/questions/381171/help-me-understand...
- duskwuff 14y ago
  As Raymond Chen would put it, though, "that would involve being on the other side of this airtight hatchway"[1]. While it's occasionally possible to execute native code from Javascript due to browser bugs, such bugs are uncommon, and are in any case quite separate from the CPU bug that this exploit claims to target. [1]: http://blogs.msdn.com/b/oldnewthing/archive/2010/12/08/10101773.aspx http://blogs.msdn.com/b/oldnewthing/archive/2010/12/08/10101...
- ObnoxiousJul 14y ago
  well, figure that if it were true, Java, python, Perl, c# are useless tools for delivering cross x86 OS code. (I just develop a side effect of the claim one can inject some code in memory bypassing all the HW/OS control). Why God these stupid Larry Wall, GvR, MS, Sun, Google, linus torvalds lost their time trying to achieve what a JS code can do in less than 1000 lines? How can I believe a code I can read and that is obviously a fraud would through the sheer power of obfuscated unused strings become such a revolution in the world of CS? Plus, I have no demonstration nor readable documents to back up the claims of this so called genius. Science is accepting what you can understand and reproduce. Not being impressed by obfuscated crap. I have no doubt this is a mystification, and I don't trust blindly what is written on the internet. I still have a brain.

Camillo 14y ago

And where is micro.dat?