Slashdot Mirror
Google Says Almost All CPUs Since 1995 Vulnerable To 'Meltdown' And 'Spectre' Flaws (bleepingcomputer.com)
Catalin Cimpanu, reporting for BleepingComputer: Google has just published details on two vulnerabilities named Meltdown and Spectre that in the company's assessment affect "every processor [released] since 1995." Google says the two bugs can be exploited to "to steal data which is currently processed on the computer," which includes "your passwords stored in a password manager or browser, your personal photos, emails, instant messages and even business-critical documents." Furthermore, Google says that tests on virtual machines used in cloud computing environments extracted data from other customers using the same server. The bugs were discovered by Jann Horn, a security researcher with Google Project Zero, Google's elite security team. These are the same bugs that have been reported earlier this week as affecting Intel CPUs. Google was planning to release details about Meltdown and Spectre next week but decided to publish the reports today "because of existing public reports and growing speculation in the press and security research community about the issue, which raises the risk of exploitation."
Shouldn't that be : Almost All Intel processors?
At the time of writing, Google believes that "every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013)" is affected by Meltdown. Google says it verified Meltdown only against Intel CPUs, but not ARM and AMD. Nonetheless, Intel has a market share of than 80% on desktops and more than 90% on the laptop and server markets, meaning that a large number of desktops, laptops, and servers are affected.
https://meltdownattack.com/
Meltdown breaks the most fundamental isolation between user applications and the operating system. This attack allows a program to access the memory, and thus also the secrets, of other programs and the operating system.If your computer has a vulnerable processor and runs an unpatched operating system, it is not safe to work with sensitive information without the chance of leaking the information. This applies both to personal computers as well as cloud infrastructure. Luckily, there are software patches against Meltdown.
Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets. In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre. Spectre is harder to exploit than Meltdown, but it is also harder to mitigate. However, it is possible to prevent specific known exploits based on Spectre through software patches.
No, KPTI doesn’t help for Spectre.
Just patch all the CPUs so they process things introspectively, with a glass of wine and some light jazz.
Time to bust out my 486!
There is no XUL, only WebExtensions...
And why AMD and ARM may not be vulnerable to Meltdown:
Someone at Intel has spun BeepingComputer - Google said that nearly all CPUs MADE BY INTEL since 1995 are likely to be vulnerable. Way to rescue your stock price, man. Good work from msmash and /. for repeating the lie too.
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
One of the things I've seen flying around, is some people are saying this can be exploited in a web browser, thanks to Javascript JIT-compiling to machine code.
I am pretty damn out of date on Javascript compilers, so I was hoping someone could explain how this is possible. Javascript doesn't have pointers. I'd think that if a Javascript programmer is capable of writing Javascript code that compiles in such a way that the programmer can create a pointer of their own making (perhaps pointing to kernel memory) and can cause code to dereference that pointer, we would all call that a severe and inexcusible compiler bug.
I mean, even if there were no processor flaw at all, but the Javascript-compiled-to-x86 code could read arbitrary memory in its own browser process, that alone would be a severe web-user-killing nightmare. How is that not a compiler bug?
Am I mistaken that a Javascript exploit is possible?
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Am I mistaken that a Javascript exploit is possible?
The fact that a given programming language gives you more or less freedom regarding how to deal with the memory management aspects doesn't change the fact that the generated applications rely on memory. In any case all these bugs seem fairly theoretically and very difficult to be actually exploited. It seems more a matter of making sure that computers are 100% safe at their most basic level than actually avoiding imminent threats.
Custom Solvers 2.0 = Alvaro Carballo Garcia = varocarbas.
32-bit ARM may be safer, because speculative execution is much, much more difficult there.
The program counter is a visible register that can be manipulated by any opcode - an explicit JUMP or BRANCH is not necessary. This makes branch prediction mostly impossible.
Most opcodes are conditional. This dependency between adjacent instructions is also a huge obstacle for speculative execution.
32-bit ARM is mostly in-order for these reasons.
https://www.jwhitham.org/2016/02/risc-instruction-sets-i-have-known-and.html
If the defect is in the microcode and they patch it in software, isn't it still vulnerable?
The defect that is happening, is that (by careful timing of cache) it's possible to see information to which the process has full access anyway.
The stupidity of some browsers is to store sensitive information in the same process as where the remotely provided javascript is JITed and executed, relying on "well, we do array boundary checks before reading them, so we should be safe from buffer overflows" for security.
Spectre works in a few corner cases because there are situation where software has full access to it's own data, but doesn't actually want to access any arbitrary data : mainly, it wants the Javascript to only read the data inside its array, and not outside were some sensitive information would be stored.
Which would fix ?
The blunder which gives access to already accessible data ?
The stupid software which keeps sensitive data and arbitrary code within reach of each other.
The first only works in a few key cases.
The second is a problem waiting to happen. If it's not Spectre today, it might be a completely different exploit tomorrow.
Doesn't seem like it would be difficult to undo or work around the software patch to access the original defective microcode.
The quick'n'dirty software correction would be :
- disabled JIT, so the arbirary code doesn't generate a thigh compact group of machine instruction that can all fit inside the CPU pipeline.
That's going to be order of magnitude more difficult to circumvent, at the cost of performance hit specific to the formelly JIT-ed code.
(But you still have a broken software that is going to get b0rken by the next coming exploit).
The formally correct software correction would be:
- keep the sensitive data and arbitrary code separate from each other. Thus even if a different exploit happens to your system, it would still not be able to access the sensitive data. You've fixed the problem forever.
The microcode/CPU correction would be :
- completely disable speculative execution, meaning a performance hit whenever there's a conditionnal jump in the code (basically everywhere).
You computer now runs like shit, and you still have broken-by-design software sitting waiting for the next exploit.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Meltdown uses out-of-order execution and a side channel attack that is unique to Intel. Spectre uses speculative execution and is more generalized, with tested proof-of-concept attack code on AMD and ARM.
On the other hand, Spectre only enables access to data to which the process had access to begin with. (Meh...)
Only a very small subset of software can actually be usefully abused, mostly due to bad software design :
- Google's demo relied on a non standard setting that turns on a JIT engine that runs user-provide arbitrary byte-code in-kernel (common, in-kernel ? What could possibly go wrong ! Seriously, there's a reason why this setting is non-standard).
- There are browser with bad designs that manage to keep sensitive data in the same context as remotely-provided Javascript code.
In other words, a problem waiting to happen. Spectre just happens to be the exploit which bit them now, but any other completely different exploit could have come in a couple of months and done similar damage.
Yup, it's bad that speculative execution may lead to some side effect, but it's working as intended.
It's the software which is stupid (or dangerous options turned on, as in the kernel) and should be fixed before another problems comes again.
---
Whereas Meltdown is an entire different level of worrying.
On Intel CPU, access rights are checked way to late, by that time speculative execution has had time to do stuff which can also be timed.
Other CPU (like AMD's) work much more sanely, doing the check first and not progressing anything. It cost a tiny bit of performance, but is more formally correct and ends up protecting against such problems.
That means that on Intel CPUs the whole set of guarantee that memory protection is supposed to give don't hold true any more.
It's the whole memory protection scheme flying out of the window.
On Intel CPUs memory protection has stoped working as it should.
The software is correct on relying on memory protection for security, it's Intel's protection that suddenly doesn't work anymore.
No matter if you write correct software.
On any other CPU protection works as it should, and non-stupid software is safe.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Technically, Spectre only reveals data to which the process had already access to begin with.
In the Google demo, it works because all in-kernel code (here: JIT-ed bytecode) has access to in-kernel data.
There's a reason why the option is non-standard.
In the few affected browser, it works because said browsers were stupid enough to keep sensitive data (passwords ?) in the same process as where remotely provided Javascript code is JITed and executed.
(I.e.: stupid design that should be fixed anyway. If not Spectre today, there's sure to be another exploitable flaw discovered before the end of this year which could also be leaking sensitive data. Always keep your sensitive data and arbitrary code execution segregated).
But correctly designed software should be unaffected.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
(BTW, thanks to the people who suggested I read the Spectre paper.)
One of the things that makes Spectre so interesting, is that we're wrong!
Long story short, is that though Javascript doesn't have pointers, it can have an array of bytes. And the compilers are amazing and apparently do a really great job of turning the Javascript into machine language.
So the Javascript basically asks for somearray[i], where i is totally out of bounds but nevertheless does correspond to some memory location that would be used, if we weren't checking array bounds. Of course, array bounds are checked, but by the time they're checked, the conditional execution has already read and used somearray[i] to touch something else. Though somearray[i] is never directly exposed, its value can be later inferred by checking to see what memory page got loaded into the cache.
Fuck. Now I see why everyone is freaking out.
If I were in charge of the Internet (heh) I'd say let's just remove all of Javascript's ability to interface with the clock, so that you can't ever figure out what was in cache vs what wasn't. No, let's not kid ourselves: my imperial directive as God of the Internet would be that web browsers should no longer ever execute any code of any kind from web pages. (Gee, I could have told myself that 20 years ago, and I probably did but I eventually had to come to accept that Javascript on the web ain't going away, no matter how much we all hate it.) You just can't sandbox things good enough.
Oh, fuckfuckfuck.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Sigh, did anyone actually read the spectre paper;
Exploiting Indirect Branches.
The bit about execution beyond software checks is explaining a specific detail about memory side effects. The above section builds on that concept to show that you can induce these memory side effects by tricking the branch predictor to execute existing code in an unexpected way.
Okay, to go into more details :
there are two things that are call spectre, which are both based around speculative execution.
The first one, which gets around software check, to which every single deeply-pipelined/out-of-order CPU that does speculative execution (lots of vendors, some as long back as mid 90s), and which is basically still "speculative execution working as intended", is the one I've described in my post.
That the one to which every piece of software running on nearly any CPU (except perhaps older Intel Atoms, Intel Xeon Phis, and older ARM 32bits as those don't do speculative execution, because as a matter of fact they have way to short pipelines) is susceptible, but which in practice isn't very concerning because it basically targets software which has "please exploit me!" design flaws written all-over it.
The second things which is called "spectre", also uses speculative execution, but is an extremely specific stuff that only targets specific CPUs :
only specific Intel CPUs are concerned, only in extremely specific circumstances. AMD CPUs are not affected. And that's expected because each CPU uses an entirely different strategy to predict branches.
Just like with Meltdown, it against boils down to Intel CPU trying to be way too much clever, trading security to shave a few performance points.
It boils down to an address (here a jump target) to even being known at the time when instruction start to pour into the pipeline. Some CPUs may try to guesstimate where the execution would go next.
The way some specific Intel CPU store their estimations means there's a risk of aliasing/confusion (CPU has learned that instruction A usually jumps to point B, but when the CPU sees instruction C it get things mixed up and think that there's a high chance it will also jump to point B and start speculatively executing there, even if that ends up not being the case and C actually jumps to a different point B).
By knowing the specific make of affected Intel CPUs, and by knowing the exact way in which this aliasing and confusion happens in that specific Intel CPUs, and by allocating a shit ton of memory (so you end up with an address that can actually be confused/aliased with your target) and by the way knowing in advance the foreign address you're trageting (because, you know, ASLR gets in the way) and spending around half an hour doing stuff (according to the Google demo) in order to get the exact thing you need so that specific Intel CPU confuses the thing exactly the way you need, then you can have the CPU guess wrong and jumping speculatively to the completely random address you've asked it to jump to (until it notice it's wrong, throws nearly everything out - except the already prefetched cache - and jumps back to the actual correct execution).
This is not something that affects every speculatively executing CPU in existence, this is not a CPU still working as it should (unlike the other exploit).
This is some specific CPU (happens to be by Intel) that each take wild guesses - way too much wild guesses - and if you know exactly how this CPU takes its too wild guesses, you can abuse to make it guess wrong. No other CPU will be affect.
Given the complexity of the taks, this is not something that you're going to see a lot in the wild and automated (not in drive-by Javascript attacks). This is something that is going to be specially crafted manually, for some very specific attacks (an attacker want to break the specific hyper visor in which it's currently staying).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]