5 ms·
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
by jimrandomh 14y ago
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.
- ars 14y ago> 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.
- SomeCallMeTim 14y agoConsidering 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?
- derleth 14y ago> the most security hardened browser, which is Google Chrome Cite, please.
- Karunamon 14y agoHere's a 2011 article: http://www.pcworld.com/businesscenter/article/245856/chrome_is_most_secure_of_the_top_three_browsers_study_finds.html 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.
- pooriaazimi 14y agoYou 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.
- Karunamon 14y agoI'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.
- pooriaazimi 14y ago
- comex 14y agoIt 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.
- munin 14y agothis 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/153144/thread 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
- duskwuff 14y agoAI39 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.
- Someone 14y agoI 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]