Hacker News new | past | comments | ask | show | jobs | submit login

By my reading, this is 100% fake. My best guess is that the author has an unstable computer, and they believe that occasional crashes while running parts of this JS mean that their exploit is working. Another possibility is that they tried to reimplement a C exploit in Javascript without understanding the difference between the languages. Either way, it doesn't work.

There's all kinds of bizarre silliness in the "exploit". They're passing URL-encoded x86 assembly to unescape() in a void context, as if that'll somehow execute the code in the result. (This technique is sometimes useful in heap sprays, but they aren't using it in a way that would work for that -- in particular, they aren't creating NOP slides or saving the result anywhere, so the resulting code would be almost impossible to hit.) They're claiming to have a "microcode VM" with a "scrambler + dynamic encoder + multi-pass obfuscator", but no such thing is in evidence. There's sillier things still, but I'll leave it for now.

I've run the PoC code, because I don't see anything to fear, and, as expected, it does nothing. The "Check vuln" button always returns "your CPU isn't buggy", because it's simply checking that the "test()" function returns 1 (which it does), and the "PoC Run!" button throws an exception, because it ends up assigning "[object Object]NaN" to the global "unescape" and attempting to call it. There is no way in hell that this code could ever have anything resembling the intended effect, on any Javascript interpreter, platform, or architecture.




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

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


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.

No clue if this is the case.


And where is micro.dat?


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.


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


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/10101...


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.


@drewcrawford, you can't even read x86 ASM? O_o

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.


I agree.

But this case does raise an issue for NaCl (which I hope will become reality one day) where you have the granularity to mess with cache hits.


From the last two lines of test it's returning 0, but the function that calls it (ThreadProc_dbg) declares a local variable result and sets it to 1, then calls test but doesn't store the return value into result so the result != 1 check is always false and the program will always display "your CPU isn't buggy!"


NaCl could make this feasible...




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: