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:
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.
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.
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.
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).
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.
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.
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.
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.
The exploit described in stackoverflow, works only for IE and a version of windows where the memory addresses are not randomized (which most modern OS do have (http://en.wikipedia.org/wiki/Address_space_layout_randomizat...) , and where calc.exe is installed (so windows + IE probably).
Hint MOV + JMP are made @ fixed address.
If the code showed is not an hoax (which I highly doubt) it would imply :
1) a specific browser (to break the gate of OS control on memory/permission by using a buffer overflow) and I don't see at first glance a buffer overflow (but let's imagine it exists),
2) a specific old OS (windows 98 or XP maybe) (for having a predictable address to which to inject the shell code)(I can't imagine an ASM code doing base of registry scanning in less than 4k to get an address of a peculiar exec/lib);
3) since it is based on specific 64bits alignment problem and since there are 32bits legacy application) it would target only the 64bits version
This makes the threat looks more like ripples in a glass of water than the tsunami that was announced.
Basically this (if it is not the hoax I think it is) would be just an exploit of a specific browser in 64bits version on a specific OS. It is not a JS exploit, it is a very specific browser name on OS name exploit in 64bits. So to say ... the whole day life in the world of software.
> 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.
Isn't exactly this how most/all heap spray js exploits work?
I wouldn't be so quick to dismiss the concept of this bug, even though the "poc" presented here is bogus.
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
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