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

Comments

Re:Almost All processors

[Lothsahn]

No. Spectre affects AMD and ARM as well (and likely other architectures too).

Best I can tell, the only CPUs guaranteed not affected by both are in-order architectures, which many older ARM (and extremely old x86) chips are.

These attacks are a sort of new category of security analysis--realizing that out of order execution can have side effects, and that programs can check for those side effects to leak program state and system memory.

Better link and description than story

[xxxJonBoyxxx]

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.

Re:Almost All processors

[Excelcia]

I just read the papers and it's actually a fascinating, and deceptively simple method. Out-of-order execution and execution prefetching causes a CPU to pre-execute instructions that are later on in the chain. If my program performs a divide-by-zero, which will cause an error when it happens, instruction pre-fetching and out of order execution has already in whole or part executed the instructions that happen after the error. So, you write your program to do this:

Something legal
Fork
Child:
Divide by Zero
Read of illegal memory

Parent:
Wait for child to crash
Read the prefetch cache to see what the out-of-order execution put in the cache when it read the illegal memory

In case that's not clear, a program forks. The child process induces an error, but after the error it has an instruction which would not normally be allowed, such as reading a portion of memory it wouldn't normally be able to. Out of order execution will already have begun performing the instruction, and because it doesn't have as rigorous controls on it, it actually reads the memory into the cache. This wouldn't be an issue, except there are ways to determine what a prefetch instruction resulted in. So the parent process waits for the child to crash and then it uses those instructions to determine the results of the prefetch which means you have just bypassed memory protection.

Re:Almost All processors

[Lunix Nutcase]

Of course it’s a flaw. It’s an unintended side-effect of speculative execution.

Re:Almost All processors

[Excelcia]

Please read the article. From it:

Google says that they've tested and verified Spectre against Intel, AMD, and ARM processors, and the attack affects desktops, laptops, cloud servers, and smartphones. The attack is also believed to affect almost all CPUs released in recent years.

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.

486

[thegreatbob]

Time to bust out my 486!

Re:Almost All processors

[AHuxley]

Re but one should at least entertain the possibility that it was.
A hardware version of PRISM? https://en.wikipedia.org/wiki/...
Room 641A Inside https://en.wikipedia.org/wiki/... most computers?
It was interesting how much of the NSA ANT catalog https://en.wikipedia.org/wiki/... connected to a computer rather than was able to work internally on a CPU as shipped?
Is the world missing the other part of the CPU catalog thats still doing collect it all missions?

Re:Almost All processors

[ilguido]

Meltdown is the real problem here and that affects only all Intel CPUs since 1995 (except for Itanium and pre-2013 Atom) and one [sic!] ARM chip (I think Cortex-A75).

Spectre is linked to two vulnerabilities: the first one is difficult to exploit and solvable via software, the second one is very difficult to exploit. Spectre allows to read memory from the same process, so it is an issue only for JIT and VM code. Meltdown allows to read memory everywhere.

Vulnerability comes down to race condition

[JoeyRox]

I read through Google's Meltdown paper (https://meltdownattack.com/meltdown.pdf). While there are several cumulative vulnerabilities that make this exploit possible, the most important of which is kernel address-space discovery via speculative data accesses which leave DCACHE lines in their wake, the root vulnerability of actually being able to read the contents of data comes down to an exception race condition. From the document:

1 ; rcx = kernel address
2 ; rbx = probe array
3 retry:
4 mov al, byte [rcx]
5 shl rax, 0xc
6 jz retry
7 mov rbx, qword [rbx + rax]

Listing 2: The core instruction sequence of Meltdown. An inaccessible kernel address is moved to a register, raising an exception. The subsequent instructions are already executed out of order before the exception is raised, leaking the content of the kernel address through the indirect memory access.
...
When the uOPs finish their execution, they retire inorder, and, thus, their results are committed to the architectural state. During the retirement, any interrupts and exception that occurred during the execution of the instruction are handled. Thus, if the MOV instruction that loads the kernel address is retired, the exception is registered
and the pipeline is flushed to eliminate all results of subsequent instructions which were executed out of order. However, there is a race condition between raising this exception and our attack step 2 which we describe below.

And why AMD and ARM may not be vulnerable to Meltdown:

6.4 Limitations on ARM and AMD
We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able tol leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.

Re:They did not test AMD or ARM

[Misagon]

No, they did test their Meltdown code on AMD and ARM but were not able to reproduce it on the chips they tested on.
That does not prove that a Meltdown-like attack on AMD or ARM is impossible, either on a different chip they did not test on or with a tweaked version of Meltdown.

From the actual article ("meltdown.pdf"):

We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD. The reasons for this can be manifold. First of all, our implementation might simply be too slow and a more optimized version might succeed. For instance, a more shallow out-of-order execution pipeline could tip the race condition towards against the data leakage. Similarly, if the processor lacks certain features, e.g., no re-order buffer, our current implementation might not be able to leak data. However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.

Re:Almost All processors

[blind biker]

No. Spectre affects AMD and ARM as well (and likely other architectures too).

Best I can tell, the only CPUs guaranteed not affected by both are in-order architectures, which many older ARM (and extremely old x86) chips are.

These attacks are a sort of new category of security analysis--realizing that out of order execution can have side effects, and that programs can check for those side effects to leak program state and system memory.

Spectre is a red herring - there is no known way it can be exploited. Meltdown is far more dangerous and it can be exploited RIGHT NOW with a simple Javascript executed in a browser. Researchers demonstrated a Javascript exploit that uses Meltdown - and there is no telling who has already been compromised. But one thing is sure: non-Intel users have not been compromised.

Frankly, this whole hoopla about Spectre seems like a well orchestrated deflection stunt by Intel PR operations. And your posts smells a bit of sockpuppetry.

arm32 versus AArch64

[emil]

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

Design errors, like having r15 as the program counter or making every instruction conditional, are problems for CPU architects rather than programmers, and it's no surprise that they disappeared in the 64-bit version of the ARM architecture. They must have made it awfully hard to implement superscalar, out-of-order execution.

Re:arm32 versus AArch64

[tlhIngan]

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.

:

This attack is a side effect of out-of-order execution. This did not happen to ARM until the Cortex A8 line of processors (Cortex A7 was still in-order). Not to be confused with ARMv7/ARMv8, since Cortex A7 and A8 implement ARMv7.

And yes, even in 64-bit ARM PC is a user-visible register - AArch32 and AArch64 are very similar to each other down to instruction coding, too. The only big thing AArch64 eliminates is conditional execution which ARM found with the Cortex A8 to interfere with superscalar execution. But just because it's harder to speculatively execute doesn't mean it's impossible. It just means you execute the instruction and then evaluate the condition later - if the condition turns out to be false, you retire the instruction without posting the effects to the architectural registers. If the instruction is true, you retire it normally. Either way, you consume the same time (an instruction not executed conditionally on ARM is considered a NOP and only wastes processor time. This fact alone makes it worthwhile to execute all conditional instructions and retire them when the end result of the condition is known - you're using up time anyhow).

Also, I'm sure the Cortex A8 notes which instructions potentially could adjust the PC (the register field of every instruction is well defined, so it's trivial to examine it and determine if it's the PC. In fact, a JMP is syntactic sugar for a MOV, as is RET. They are internally MOV instructions (you'll note that every function ends with "mov pc,lr", which moves the link register (old PC before call) to the PC, thus returning.

Modern thumb interworking though uses "blx" which is branch-to-link-and-exchange because you need to load both the LR and the old CPSR register (which controls the THUMB state), so you return back to the right mode and is the only way if you're mixing ARM and THUMB instructions together (aka interworking).

Re:Almost All processors

[dryeo]

K5 was the first totally in-house designed AMD CPU and one of the first to do out of order execution, which is what these bugs exploit. Whether it is actually vulnerable would have to be tested.
https://en.wikipedia.org/wiki/...

Re:Almost All processors

[sl3xd]

Frankly, this whole hoopla about Spectre seems like a well orchestrated deflection stunt by Intel PR operations.

I'd caution against a false sense of security, based on one's choice of processor for your personal desktop.

There's no disagreement that "Meltdown" is the greater problem, and affects pretty much any Intel chip still functioning. It's important to remember that it's virtually guaranteed that connect to many servers that uses an affected processor every day. Those of us who maintain cloud infrastructures are particularly unhappy with the situation.

The fact that Meltdown is worse shouldn't distract from the fact that Spectre is bad.

The paper on Spectre is written by a number of people working for a number of organizations, but Intel isn't one of them. It has the following statement:

We have also verified the attack’s applicability to AMD Ryzen CPUs. Finally, we have also successfully mounted Spectre attacks on several Samsung and Qualcomm processors (which use an ARM architecture) found in popular mobile phones

They go on to state they've verified the weakness on x86 using C and JavaScript (+ Google V8 JIT) bytecode.

Much like JavaScript cryptocurrency mining , the fact that something is hard doesn't mean it's not worth doing to those interested, and having browser-based JavaScript exposing data isn't a good thing.

Meltdown can be fixed fairly easily (AMD certainly shows it's possible to avoid the problem). Spectre, however, will be with us for a long time.

Re:Almost All processors

[silverdirk]

The attack checks which rows of cache got evicted by reading across a large array, requesting behavior by another process, and then re-reading the array timing how long each read takes. Each iteration of the attack reveals a byte of memory by identifying which cache row it affected.

Re:Almost All processors

[martyros]

Spectre is a red herring - there is no known way it can be exploited.

Google has exploited it. Look at Google Project Zero's write-up of these bugs. Spectre corresponds to "Variant 1 and Variant 2" in that blog post. You'll see that they successfuly exploit both, the second from a KVM guest.

It is true that Google cheat a little here, by using Linux's eBPF JIT engine (which, I hear, is normally disabled by default). From the blog post:

To be able to actually use this behavior for an attack, an attacker needs to be able to cause the execution of such a vulnerable code pattern in the targeted context with an out-of-bounds index. For this, the vulnerable code pattern must either be present in existing code, or there must be an interpreter or JIT engine that can be used to generate the vulnerable code pattern. So far, we have not actually identified any existing, exploitable instances of the vulnerable code pattern; the PoC for leaking kernel memory using variant 1 uses the eBPF interpreter or the eBPF JIT engine, which are built into the kernel and accessible to normal users.

Scale of the attacks.

[DrYak]

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.