Intel Core 2 Duo Remote Exec Exploit in JavaScript?(1337day.com)
1337day.com
Intel Core 2 Duo Remote Exec Exploit in JavaScript?
http://1337day.com/exploits/18984
28 comments
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
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.
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).
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.
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.
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...
> 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...
[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.
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 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.
> 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.
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...
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.
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.
Considering there are so many different JavaScript engines (IE, several FireFox options, Chrome's V8, WebKit's engine...), how could ONE exploit affect them all?
Even taking C code and running it through two different compilers (or the same compiler with different options) will often produce different executable code. So one would assume each JavaScript JIT compiler would produce code differently, and yet there's no comment on what browsers are vulnerable?
Did I miss the memo that all of the above compilers are sharing the same JIT code?
Even taking C code and running it through two different compilers (or the same compiler with different options) will often produce different executable code. So one would assume each JavaScript JIT compiler would produce code differently, and yet there's no comment on what browsers are vulnerable?
Did I miss the memo that all of the above compilers are sharing the same JIT code?
It does not work as advertised.
The bizarrely written code (no, really, read it) does not do anything useful as is; even bypassing the apparently intentionally erroneous JS, the best I can tell is that it's expecting you to modify your JS interpreter to make "unescape" execute the shellcode contained in the string, which makes it not a "remote exploit" but a (potential) local exploit someone stuck into an HTML page for some ridiculous reason.
The bizarrely written code (no, really, read it) does not do anything useful as is; even bypassing the apparently intentionally erroneous JS, the best I can tell is that it's expecting you to modify your JS interpreter to make "unescape" execute the shellcode contained in the string, which makes it not a "remote exploit" but a (potential) local exploit someone stuck into an HTML page for some ridiculous reason.
this is not unknown. this appears to be an attempt to exploit AI39, which has been known for the last five years http://kerneltrap.org/mailarchive/openbsd-misc/2007/8/8/1531...
and if you want to read the actual bug in Intel documentation, it is here: ftp://download.intel.com/design/processor/specupdt/313279.pdf
and if you want to read the actual bug in Intel documentation, it is here: ftp://download.intel.com/design/processor/specupdt/313279.pdf
AI39 is apparently "Cache Data Access Request from One Core Hitting a Modified Line in the L1 Data Cache of the Other Core May Cause Unpredictable System Behavior". But Javascript isn't multithreaded, so I'm not sure how the author claims to be tickling this bug. (Their commented-out "THREATED[sic] IMPLEMENTATION" doesn't invoke any form of multiprocessing. In fact, it doesn't do anything at all.)
Additionally, AI39 doesn't even affect any of the CPUs they tested on! It affected some early Conroe steppings, but the Core2 (T5750) they tested on was Merom, released several years later, and the Atom is a completely different µarch altogether.
Additionally, AI39 doesn't even affect any of the CPUs they tested on! It affected some early Conroe steppings, but the Core2 (T5750) they tested on was Merom, released several years later, and the Atom is a completely different µarch altogether.
I haven't looked at the page at all and the Intel PDF I could find wasn't too informative for me, but the reasoning could be that there are other processes running on the CPU. If 'hitting a modified line' means 'requesting an address that would be mapped to the same cache line in the other core' and not 'requesting an address that is in the cache of the other core', this approach would be viable [However, if that is the case, there have to be other conditions involved, as it cannot be that simple, as without them, it would be so easy to hit this problem that Intel would have detected it before selling one of these]
> If you are using Noscript and also blocking Flash, then you are probably safe
If I understand this bug correctly, then no you are not. My initial impression is that it is loading a specific sequence of bytes into memory than is then mistakenly executed by the CPU.
You don't need javascript to put bytes into memory.
It could be they need javascript to cause some sort of memory (string) copy at the same time.
If I understand this bug correctly, then no you are not. My initial impression is that it is loading a specific sequence of bytes into memory than is then mistakenly executed by the CPU.
You don't need javascript to put bytes into memory.
It could be they need javascript to cause some sort of memory (string) copy at the same time.
> the most security hardened browser, which is Google Chrome
Cite, please.
Cite, please.
Here's a 2011 article:
http://www.pcworld.com/businesscenter/article/245856/chrome_...
Summary:
* Study (commisioned by GOOG but methodology is open for inspection) puts them #1 out of 3 (being IE and Firefox)
* Patched faster and more often than others
* Untouched at least year's pwn2own
Edit: Oddly enough, this was the #1 result for "chrome most secure browser" on Google. One should really do a cursory search before throwing the citation flag.
http://www.pcworld.com/businesscenter/article/245856/chrome_...
Summary:
* Study (commisioned by GOOG but methodology is open for inspection) puts them #1 out of 3 (being IE and Firefox)
* Patched faster and more often than others
* Untouched at least year's pwn2own
Edit: Oddly enough, this was the #1 result for "chrome most secure browser" on Google. One should really do a cursory search before throwing the citation flag.
You should use (vanilla) Webkit or Chromium if you want to be really safe. As I'm sure you know perfectly well, Chrome is closed source and you really don't know what's going on inside it (Chromium, that is a different beast, is open source).
Chrome might be safer (than Safari, Firefox or IE) for this kind of malware, but I sure as hell wouldn't run a browser made by an company that makes money by collecting personal data for the benefit of advertisers if I wanted to be "safe". I see no reason to believe Microsoft, Apple or Google haven't put some spyware/backdoor in their browsers. But I really don't care about it, so I use Safari which is the best browser on Mac, IMO.
Chrome might be safer (than Safari, Firefox or IE) for this kind of malware, but I sure as hell wouldn't run a browser made by an company that makes money by collecting personal data for the benefit of advertisers if I wanted to be "safe". I see no reason to believe Microsoft, Apple or Google haven't put some spyware/backdoor in their browsers. But I really don't care about it, so I use Safari which is the best browser on Mac, IMO.
I'm not going to touch the typical FOSS arguments because that is going to lead down a rabbit hole we've both been down about a thousand times I'm sure.
That said, while Safari is a nice browser, it's horribly insecure. Just looking at Pwn2Own, it gets killed straight off every year, and those involved usually remark about how trivial it is.
That said, while Safari is a nice browser, it's horribly insecure. Just looking at Pwn2Own, it gets killed straight off every year, and those involved usually remark about how trivial it is.
My impression is that Pwn2Own skews hard towards Safari for two reasons: the Air that's normally a prize is more desireable than the random cruddy Windows laptop, and Flash is a much softer security target than Safari itself, so that's usually what gets exploited.
You're right. I said I use it because I really don't care that much about security, and find it better suited to my needs. But if I did care about security, I certainly wouldn't run Chrome either (for the reasons stated); I'd use Webkit or Chromium, or plain old lynx like our friend Richard.
> Untouched at least year's pwn2own
That's so '11... ;-)
> Team VUPEN: 0day: Google Chrome: Full sandbox escape and code execution
http://pwn2own.zerodayinitiative.com/status.html
Safari was apparently the only one without a 0day, though exploited via CVE-2011-0115 and CVE-2010-0050, weird since the former is patched since 5.0.4 [0] and the latter is fixed in iOS 3.1.3 [1] and Safari 4.0.5 [2]. Aren't they supposed to target fully patched, latest OSes and browsers?
[0] http://support.apple.com/kb/HT4566
[1] http://support.apple.com/kb/HT4225
[2] http://support.apple.com/kb/HT4070
That's so '11... ;-)
> Team VUPEN: 0day: Google Chrome: Full sandbox escape and code execution
http://pwn2own.zerodayinitiative.com/status.html
Safari was apparently the only one without a 0day, though exploited via CVE-2011-0115 and CVE-2010-0050, weird since the former is patched since 5.0.4 [0] and the latter is fixed in iOS 3.1.3 [1] and Safari 4.0.5 [2]. Aren't they supposed to target fully patched, latest OSes and browsers?
[0] http://support.apple.com/kb/HT4566
[1] http://support.apple.com/kb/HT4225
[2] http://support.apple.com/kb/HT4070
> One should really do a cursory search before throwing the citation flag.
No, it's up to the people making the claim to defend it.
> Patched faster and more often than others
Not necessarily a good thing. Also doesn't really help people off of Google's forced-update scheme.
Also, plugins are an important part of any browser now; NoScript and the ad blocking/anti-tracking tools work better on Firefox.
No, it's up to the people making the claim to defend it.
> Patched faster and more often than others
Not necessarily a good thing. Also doesn't really help people off of Google's forced-update scheme.
Also, plugins are an important part of any browser now; NoScript and the ad blocking/anti-tracking tools work better on Firefox.
As the creator of [citation needed], I refute this. There is no need for someone to believe a claim from a particular source if there is no citation involved. It is indeed up to the author to provide the citation.
However, should someone else provide a citation, then this will also do - and the author should really thank that person for doing the hard work in providing a more meaningful discussion.
However, should someone else provide a citation, then this will also do - and the author should really thank that person for doing the hard work in providing a more meaningful discussion.
>No, it's up to the people making the claim to defend it.
Perhaps, but it adds much more to the discussion and comes across as less prickish if you say something along the lines of "I don't see any data to support that, could I see yours?" rather than "Citeplz".
Especially when it's literally one google search away on result #1. It just smacks of laziness.
And while I agree with you on plugins, we're talking security. I was going by the study's methodology (which seems mostly sound).
Perhaps, but it adds much more to the discussion and comes across as less prickish if you say something along the lines of "I don't see any data to support that, could I see yours?" rather than "Citeplz".
Especially when it's literally one google search away on result #1. It just smacks of laziness.
And while I agree with you on plugins, we're talking security. I was going by the study's methodology (which seems mostly sound).
> the ad-blocking and anti-tracking tools work better on Firefox
Cite, please.
Cite, please.
> No, it's up to the people making the claim to defend it.
Cite, please.
Cite, please.
This is true IIRC, or at least, was. Chrome extensions can only hook in to the DOM after it has been evaluated. You can see this occasionally with Adblock when ads flicker in briefly.
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"?
The code is obscure, therefore the idiots think it is profound. Or rephrased by JG: the bigger the troll, the easier it shall pass.
The more I read HN, the more bewildered I get at the gullibility that seems to prevail amongst self called geeks and smart entrepreneurs.
Give me a rope please.
The more I read HN, the more bewildered I get at the gullibility that seems to prevail amongst self called geeks and smart entrepreneurs.
Give me a rope please.
I saw this in the morning on my phone with a tiny screen. I couldn't read it properly but figured that since it already had so many votes up, it must be legit, therefore important. So I hit the upvote button too. I know, I'm an idiot! :-D My apologies for playing a part in pushing this up.
I'm more amazed you think you're so brilliant but you don't understand how Hacker News works. People vote up stuff they find interesting, not stuff they know 100% is the truth so-help-you-god.
People think this is interesting. I voted it up. I have no idea if it's true. I don't think a up-vote has ever been code for "also, this is 100% true"
Sorry I'm so much more gullible than you.
People think this is interesting. I voted it up. I have no idea if it's true. I don't think a up-vote has ever been code for "also, this is 100% true"
Sorry I'm so much more gullible than you.
Well, upvoting means I think it is interesting. You usually dont upvote hoaxes I hope (especially the unfunny one).
This is clearly an hoax in the first form (JS exploit).
At most (if real) it is just an exploit of a specific browser (version) on a specific OS. If you go on «hacker» news, I am very surprised you have no IT culture. I suggest you should read http://www.newsoftheworld.co.uk/ if you want untrustworthy sensational news, and consider not upvoting when you are clueless on a topic.
Less noise, more signal is a very old hacker motto. You obviously don't get it.
This is clearly an hoax in the first form (JS exploit).
At most (if real) it is just an exploit of a specific browser (version) on a specific OS. If you go on «hacker» news, I am very surprised you have no IT culture. I suggest you should read http://www.newsoftheworld.co.uk/ if you want untrustworthy sensational news, and consider not upvoting when you are clueless on a topic.
Less noise, more signal is a very old hacker motto. You obviously don't get it.
wow... you really are obnoxious!
Thanks. I do despise stupid brainless people: they are a threat to all the things I believe in: democracy, science, fun, sex, good taste & style.
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:
I haven't tried too much on the code that actually crashing the computer (or whatever it does) since just the test puzzles me.
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.
> The variable 'result' is (visibly) untouched
Actually it is invisibily touched by that call to unescape(). The assembly code in the comments is what is generated by the interpreter, and that's where the trick happens.
Actually it is invisibily touched by that call to unescape(). The assembly code in the comments is what is generated by the interpreter, and that's where the trick happens.
No. The interpreter doesn't generate that. They have taken the assembly, placed it in a string, and then done nothing more.
There is no obvious attempt to actually get the JS engine to do anything out of the ordinary. The string '%u31C9%u5589%uE55D%u2EF8%uC390%u9090'
is simply the unicode escaped version of the assembly above. The goal of this exploit would be to get the interpreter to set PC to the address of that string. There is no obvious attempt to do that.
Just compare the decoded opcodes in the DISASM comment to the contents of the string.
There is no obvious attempt to actually get the JS engine to do anything out of the ordinary. The string '%u31C9%u5589%uE55D%u2EF8%uC390%u9090'
is simply the unicode escaped version of the assembly above. The goal of this exploit would be to get the interpreter to set PC to the address of that string. There is no obvious attempt to do that.
Just compare the decoded opcodes in the DISASM comment to the contents of the string.
I noticed the same, but then figured out that the PoC is incomplete like the engine function. I assume that's on purpose. I look forward this gets the attention of security experts to know if this is real or not.
There's "incomplete", and then there's "broken", and then there's this code. It's not even broken; "broken" would imply that it could be fixed. There's simply nothing there.
See my analysis: http://news.ycombinator.com/item?id=4246338
See my analysis: http://news.ycombinator.com/item?id=4246338
[deleted]
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.
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...)
(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?
> I'm not smart ...
Off topic, but one person being intelligent in a field you're potentially not familiar with does not make you "not smart". Putting yourself down isn't cool or honorable.
That being said, I'm also extremely curious what's going on here :)
Off topic, but one person being intelligent in a field you're potentially not familiar with does not make you "not smart". Putting yourself down isn't cool or honorable.
That being said, I'm also extremely curious what's going on here :)
Sorry. Melancholy frequently gets the better of me.
RegEx was talking to himself, not you, so don't worry.
Feh, it's just a slight incompatibility with the ways you two communicate. Some people think "hate" is too strong of a word to be used lightly, and it can get awkward when they talk to a person who casually says "I hate <name>".
Being unaware of a detail in a specific field does not imply lack of intelligence, but lack of intelligence probably does imply ignorance of field-specific details. Perhaps the commenter is truly claiming to be unintelligent.
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.
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 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 exploit can't be disproved by saying "read the code". The point is that a CPU bug causes the code to run off the rails and do something that it isn't even written to do. Examining the source code shows an infinite loop running along. Dumb and harmless, right? Not if a CPU bug corrupts the L1 cache memory in which the loop is running. Now that loop could jump anywhere and do anything. You can never prove behavior at that level from abstracted high-level source code alone.
As for the Hacker News reaction, whether the exploit actually works is somewhat immaterial. Even if it doesn't, the story opens up new and interesting lines of thinking around CPU architecture and security. It's interesting hacker material even if there's no bug here.
As for the Hacker News reaction, whether the exploit actually works is somewhat immaterial. Even if it doesn't, the story opens up new and interesting lines of thinking around CPU architecture and security. It's interesting hacker material even if there's no bug here.
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.
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.
Yep, mixing data with executable code sounds like a great idea.
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...
[0] https://developers.google.com/v8/design#mach_code
[1] http://www.webkit.org/blog/214/introducing-squirrelfish-extr...
I don't see why/where the code generator is involved here. The posted "exploit" doesn't appear to work at all, implying that either it's not complete (so discussing how it works is kind of pointless) or just bogus.
There's nothing that I see that makes it obvious that it's attacking the JIT logic specifically. It's most reminiscent of the fairly old heap spray techniques which require an additional exploit anyway.
For instance the function for testing existence of the bogus microcode is: function test(result) { // giant comment explaining the asm used to test for the vulnerability unescape('%u31C9%u5589%uE55D%u2EF8%uC390%u9090'); return 0; }
Presumably the call to unescape is intended to convert the encoded shellcode into somthing useful. But there does not appear to be anything done to actually execute the shellcode. The historical way of doing this (blocked by DEP) is to fill the heap with copies of the string, and then use another exploit to jump into the heap at somewhere likely to contain your code. There are ways to bypass DEP, but this doesn't appear to try even that.
Honestly it looks like someone has simply taken the assembly used to the exploit, put it in a string (using numeric character escapes), and then done nothing else.
That it is referring to launching threads makes me wonder if this isn't just someone converting a pre-existing C program into something that at least parses as JS.
There's nothing that I see that makes it obvious that it's attacking the JIT logic specifically. It's most reminiscent of the fairly old heap spray techniques which require an additional exploit anyway.
For instance the function for testing existence of the bogus microcode is: function test(result) { // giant comment explaining the asm used to test for the vulnerability unescape('%u31C9%u5589%uE55D%u2EF8%uC390%u9090'); return 0; }
Presumably the call to unescape is intended to convert the encoded shellcode into somthing useful. But there does not appear to be anything done to actually execute the shellcode. The historical way of doing this (blocked by DEP) is to fill the heap with copies of the string, and then use another exploit to jump into the heap at somewhere likely to contain your code. There are ways to bypass DEP, but this doesn't appear to try even that.
Honestly it looks like someone has simply taken the assembly used to the exploit, put it in a string (using numeric character escapes), and then done nothing else.
That it is referring to launching threads makes me wonder if this isn't just someone converting a pre-existing C program into something that at least parses as JS.
Exploits have existed in web browsers since they were invented. Everything is eventually executed at some point, it really just depends on how good the thing doing the decoding/encoding is. Just because something is slow and seemingly encapsulated doesn't mean it is safer than running it lower to the metal. That's almost like security through obscurity, adding layers because you think it's safer, not because you know it is. Sometimes the layers are what make it more vulnerable, not less.
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?
Apparently the "subset of popular browsers" it works on is the null set - it doesn't work on any browser on any operating system on any architecture, C2D or otherwise.
I'm curious why the HN title hasn't been updated yet.
I'm curious why the HN title hasn't been updated yet.
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
It's intentionally incomplete. Take a look at the "engine" function, it's body is empty.
It's a pretty weird idea to suggest there is a universally applicable CPU bug that can get that code to run.
There are substantial differences in the ways various Javascript VMs work, how and where they store strings, how code is compiled, etc. Would it work under Rhino? Firefox? Old Safari?
There are substantial differences in the ways various Javascript VMs work, how and where they store strings, how code is compiled, etc. Would it work under Rhino? Firefox? Old Safari?
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?
A cache bug allows you to overwrite effectively any area in memory, including in this case kernel memory.
Since you can overwrite kernel memory all you need to do is change the uid of your process to 0, and then the OS will happily do whatever you want.
Alternatively just overwrite the address of a popular system call to a function that you prefer.
With a little metasploit code this thing should be completely cross platform.
Since you can overwrite kernel memory all you need to do is change the uid of your process to 0, and then the OS will happily do whatever you want.
Alternatively just overwrite the address of a popular system call to a function that you prefer.
With a little metasploit code this thing should be completely cross platform.
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 ?
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...
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.
Looking at the page source the only Javascript that is running is Google Analytics so we are probably safe. Your antivirus probably doesn't like http://1337day.com/.
I copy/pasted the text and sent it to my gmail address (to archive it), and gmail rejected the message with "Our system detected an illegal attachment on your message.". (There was no attachment, but just the main part).
So it might be possible that some parts of the code match existing malware.
So it might be possible that some parts of the code match existing malware.
It's almost certainly just flagging the long blob of %uXXXX escapes as characteristic of heap spray exploits, not detecting any specific exploit.
Ok cool. Thanks!
No wonder it doesn't work. The </html> tag is in the wrong place :p
My god, they're even using invalid markup?!
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.
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.