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.

Here's a quick summary of what this is. It's a partially-obfuscated piece of malware, which claims to demonstrate a zero-day (that is, unpatched and previously unknown) security vulnerability affecting Intel Core 2 Duo and Intel Atom processors, allowing privilege escalation from inside a Javascript interpreter up to kernel memory. I don't know whether it actually works, since I'm not brave enough to experiment with it, but it's likely that it does.

If this works as advertised, then if you have an affected CPU, it is a zero-day exploit affecting every web browser on every operating system, both desktop and mobile, as long as you have Javascript enabled. Until a workaround has been found, any site which serves you Javascript or any of its advertising networks could use it to give you malware.

If you are using Noscript and also blocking Flash, then you are probably safe. To protect yourself, you should, first of all, use ad-blocking software, because ad networks are more likely to distribute malware than the sites they advertise on. Second, you should use only the most security hardened browser, which is Google Chrome; it's not clear whether Chrome's hardening will actually help, but it's likely that it will, and also that it will be the first to have a workaround. And third, you should be immediately suspicious if your browser crashes unexpectedly.

112 points right now and still no one has confirmed the exploit is working... What happened to the good old "extraordinary claims require extraordinary evidence"?

So what's going on here?

I have been trying to follow along but I'm confused why anything happens.

There's a test button that calls ThreadProc_dbg(bug) which then calls test(result), which in turns has some assembler code commented out and finishes with:

    	unescape('%u31C9%u5589%uE55D%u2EF8%uC390%u9090');
	return 0;

The variable 'result' is (visibly) untouched by the function but ThreadProc_dbg tests its value to see if the processor is vulnerable or not. So just the test() function has the good stuff. (assuming it works) So either the assembler code does something even though it's commented out, or the unescape is not happy but I'm not sure why…

I haven't tried too much on the code that actually crashing the computer (or whatever it does) since just the test puzzles me.

An explanation attempt: This demo consists of actually two programs. A test loop, which gets exploited and the malicious code. The test loop needs to run until patched. It is completely running from the cache. When the exploit runs, it modifies the 4 first bytes of the cached loop into 4 NOPs via the cache exploit. When the change happens, the exploit is successful.

This test code is save for c2d users to try. It just checks, if the cache modification is possible.

A real exploit would combine this with other explotation code and would change the machine code of the test loop into a jump or a call.

The real scary part of this is, that it is possible to patch code despite of access rights. If the loop is really changed, I have no doubt that this can be made into an effective exploit.

Relevant: http://www.cs.dartmouth.edu/~sergey/cs258/2010/D2T1%20-%20Kr...

(The PoC as it is doesn't actually do anything...)

I'm not smart, can someone give me a rundown of what's going on here?

Has anybody confirmed this is working yet? If not it seems like an elaborate joke.

This placed a malicious file in my cache. I'd recommend not visiting for now.

Wow.

I'm dumbfounded at how much more clever and sophisticated attacks get. It will never end! I fear that I cannot be of much use anymore.

I remember back when buffer overflows was the exploit and I viewed it as some kind of sorcery, even though I understood it.

I guess so long as software keeps getting written, exploits can be found, and if you plumb the depths of specification, you can find holes, but they're so much more harder to find now. :(

Maybe I'm feeling my age? Security is a game for the young? Or at least more energetic.

Whoever upvoted that should seriously consider a career away from computers. Away from anything requiring critical thinking actually.

This is on par with some 90s hoaxes claiming some emails could burn your CPU.

The code isn't even hard to follow AT ALL! There is no way it will ever display anything but "<h1>[-] your CPU isn't buggy!<h1>". There is like 5 lines of very simple code to read to achieve this conclusion.

Very disappointed in Hacker News.

This sort of article makes me loose faith in hackernews. It's 166 points by now and getting more, yet when you look at the code it's obviously fake. It does not do anything. Why people who cannot confirm or deny such claims upvote this? You don't even have to read the code - it's blatantly obvious you cannot have an exploit using a bug in CPU cache strategy that affects all the JS vendors!!!

Allowing JavaScript is only going to get closer to being equivalent to allowing untrusted, unsigned code on your machine. Atwood's Law applies to malware too.

Before I edited this comment, I had a laugh at the expense of people who think I'm in some way misguided for using NoScript and complaining when sites break with JavaScript off. That was wrong. I think that those critics are also wrong, though, and this sort of thing is why. Even if this particular code is a non-starter, the plausibility of this kind of threat, this kind of nightmare scenario, is a huge problem. JavaScript is a general-purpose programming language that's present on nearly every user-facing computer in the world, with all the security issues that come with that. It is in some ways the world's biggest and most-rewarding malware attack surface. A working 0-day attack in JavaScript itself could be worth millions or billions in the right hands.

If I have a Core 2 Duo, should I be concerned?

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

this does nothing, nothing at all, it's fake.

I don't have a C2D processor to test this with, but does this work on all browsers or some subset of the popular ones?

Why would they obfuscate this if they intended to publish it? Maybe this means it was not meant to be published...

Tested it on my c2d (P8700). In chrome it claimed my cpu is not buggy, and in firefox the script didnt even work.

PoC did not work on a Core2Duo L7100

So how does a bug in the CPU cache controller cause a remote execution exploit? You can write an exploit into memory, have it cached somehow, trigger the bug, and then the CPU will execute the wrong data in the CPU cache?

Seriously, how do people go about finding bugs like these ? looks like they start from assembly code then try to trigger that code in javascript.

Any one tested this ?

so the horror story here appears to be that from a javscript application i could get a blind write to any location on the system.

this is powerful but undirected. locations of important code have been randomized in your operating system for quite some time. if this technique even works, to turn it into an 'exploit' you would need to know the location of the code that you want to patch, and knowing this requires yet another exploit...

Just opening this link threw security warnings from my antivirus. As such, I'd pull this from HackerNews. AMD processor.

No wonder it doesn't work. The </html> tag is in the wrong place :p

More importantly will Apple give me a replacement for my 2008 IMac? :P

Impressive.

mouhahah okay read the code. It mainly writes: you have been hacked on a web page. End of the story.