Intel Core 2 Duo Remote Exec Exploit in JavaScript?

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.

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.

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;

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

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.

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

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.

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.

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.

[0] https://developers.google.com/v8/design#mach_code

[1] http://www.webkit.org/blog/214/introducing-squirrelfish-extr...

Any one tested this ?

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