Google's Project Zero Team Discovered Critical CPU Flaw Last Year (techcrunch.com)

An anonymous reader quotes a report from TechCrunch: In a blog post published minutes ago, Google's Security team announced what they have done to protect Google Cloud customers against the chip vulnerability announced earlier today. They also indicated their Project Zero team discovered this vulnerability last year (although they weren't specific with the timing). The company stated that it informed the chip makers of the issue, which is caused by a process known as "speculative execution." This is an advanced technique that enables the chip to essentially guess what instructions might logically be coming next to speed up execution. Unfortunately, that capability is vulnerable to malicious actors who could access critical information stored in memory, including encryption keys and passwords. According to Google, this affects all chip makers, including those from AMD, ARM and Intel (although AMD has denied they are vulnerable). In a blog post, Intel denied the vulnerability was confined to their chips, as had been reported by some outlets. The Google Security team wrote that they began taking steps to protect Google services from the flaw as soon as they learned about it.

Comments

Re:Technical Details

[darkain]

Whoops, wrong link. I meant this one: https://googleprojectzero.blog...

Re:Reading the vulnerability...

[93 Escort Wagon]

This is more of a server attack and a web host attack.

You might want to read this Mozilla blog post.

https://blog.mozilla.org/secur...

Re:Intel's press release language is interesting.

[hcs_$reboot]

Intel PR translation.

AMD, ARM mostly immune to the bad stuff

[Anonymous Coward]

There are two exploits revealed here: Meltdown and Phantom

Intel, AMD, and some/all ARM chip are vulnerable to at least one of the two Phantom attacks, but patching Phantom will not produce any significant performance reductions.

At this time, only Intel systems have exhibited vulnerability to Metldown. Patching Meltdown comes with serious consequences.

So AMD is basically correct in stating that they are not in the same position as Intel .

Nope, no virtual machine needed.

[DrYak]

This is more of a server attack and a web host attack.

No, it's not specific to web servers.
They do use web servers as an example of where the exploit might be applied, but it's not specific.

Basically, this exploit allows to abuse the way speculative execution is done to leak information out of the kernel space into the user space.
(And there are presentation at the CCC of successful abuses done... in Javascript. In a browser).

For more details :

most modern CISC processors (Intel - except for Atoms and Xeon Phi - AMD, etc.) are pipelined and do out-of-order execution.
Executing a CISC instruction requires several steps (micro-ops) and for performance reasons, they keep several instruction in flight (Once instruction A goes out of step 1 and into step 2, you can try already pushing instruction B into step 1).
To gain even more performance, CPUs try to be clever about this (instruction B actually needs results of instruction A, so it needs to wait. But the next instruction C actually can already be started, it doesn't depend on anything still in the pipeline).
Bordering on crystal ball-clever (the next instruction B is a conditional jump. But it looks like a loop, so there's a high chance that it will jump back and repeat. We might as well start working back on instruction A, in case we are correct about this jump).
That's speculative execution : working in advance on stuff that might not even be needed.
(Sometimes, you end up needing to bail out of your speculation, throw the work away and restart because you got your crystal ball wrong. But it's better than just sitting there waiting).

now about memory :
any modern processor worth its salt has memory protection, meaning it handles access rights : Which process can read-write which virtual addresses ?
Usually, sensitive information in the OS is shielded away from the regular software.
On a modern Linux, you can't crash the whole system by writing junk at the wrong address, like you used to do in the old MS-DOS days.
If your software attempts to read something out of the system, the read attempt will be rejected.

the exploit relies on how these both play together.

It happens to be that, in the case of Intel's processors (but not of AMD's), the step where the memory page is loaded from the DRAM stick into the cache happens before the check if the read is valid.
By the time the Intel CPU does the check and notice that the read is invalid and rejects it, quite a lot has happened.
(Things got loaded into cache, other instructions have started their speculative execution in the pipeline, etc.)
These things are measurable (you can measure the timing of some computation to guess what's in the cache and what's not).

Meaning that it's possible to leak sensitive information, that normally pertain in to the OS and shouldn't be application-accessible, by doing a ton of such speculative-execution and timings.
At CCC there was some presentation of this done in javascript: Technically, your browser right now could be executing some random javascript shit from some shaddy website in one of your background tabs and trying to learn as much from your OS as possible.
Such information could further be used while mounting privilege escalations, or other attacks.

In the specific situation of AMD processors, the check is done much earlier (according to their lklm post) and thus not much else has happened already, and there's not much leak from which you could learn.

I have no idea how ARM64 are affected. (But it might also be the cache getting populated before the read attempts get rejected).

Re:Nope, no virtual machine needed.

[fubarrr]

Yes, the problem is if you check for page faults before starting executing a branch, you must check page faults for all branches, but if you check it post factum you need to do page fault check only for the correct branch, thus greatly reducing performance penalty of memory protection checks.

AMD64: 2 separate things

[DrYak]

Doesn't affect AMD64

The horrible leak that gives access of kernel information to any userspace software that was revealed yesterday doesn't affect AMD64 :
AMD processor reject invalid access much earlier in the pipeline and nothing much happens before that point (e.g.: loading into cache) that could be measured by timing, etc.

In the google paper, they are abusing a different set of anomalies were an application end's up reading it's own memory (yay... ). That *could* be affecting AMD64, but :
- it's only an application in user-space accessing it's own in user-space memory.
- by enabling a few non-standard kernel settings, you end up with a situation where you can send eBPF (the bytecode used by modern packet filtering) to a in-kernel JIT, and it's execution will end up with some in-kernel code reading its own in-kernel memory.

The main big difference, the take-home message:

- on Intel CPU, you have a violation of boundary separation : an end-user application could access information leaking out of the kernel.
- on AMD CPU, this does not happen : you only access information on the same side of the separation boundary.

Or in other words :
- On Intel are in deep shit right now. They need a serious circumvention around it. It means context switch - each time a software calls a system call (e.g.: to access the file system) - the OS needs to flush out all the sensitive information to make them unreachable by the exploit. The end result : massive performance hit.

In all seriousness....

[DrYak]

What about my Commodore 64?

In all seriousness :

- old, in-order, non-pipelined CPU like the 6502 in your good old trusted C64 don't do speculative execution and thus aren't affected specifically by such exploits.

but:

- your 6502 doesn't do any form of memory protection : any piece of software can access any part of the whole system (because poking weird memory location is how you control the hardware on such old system) so any software has full access to anything.
So you C64 is leaking sensitive information.

(Later 68k motorola CPU (68030 and up) eventually started to include an built-in MMU to protect memory access, and thus later Amiga machine featuring them (A2500/30, A3000) can be made imune to OS information leaking into userland. That would the first Comodore hardware - vaguely remote cousin of your C64 - to do so)

Yup, i'm giving a technical answer to a joke.

Intel stock sold

[sad_]

It has also come to light that Intel CEO sold $24M in stock when he was aware of the issue.

http://www.businessinsider.com...

Attack class vs. whole design

[DrYak]

The concern is that we have a whole new class of attack, exploiting a fundamental feature of the architecture of all modern CPUs. Yes, AMD is less vulnerable to the attacks so far devised, but that is an accident. AMD didn't design to protect against this class of attack, because they didn't know about it.

Maybe the attacks are tiny bit interesting because they abuse the speculative execution.
(CPU starting to execute stuff before hand, for performance reason).

But there's a big major difference.

In the case of the Meltdown exploit, the stuff that affect Intel-only CPU, the whole guarantee that memory protection gave don't hold anymore.
The MMU is made completely irrelevant.
It entirely breaks whole concepts of computer security.
You might as well go back to MS-DOS era / pre-68030 era, when any piece of code could read/write any arbitrary memory location without any restriction.

It's BIG.

Intel has made a bit of a gamble : for speed purpose, it's a bit faster to postpone the check a little bit further down the pipeline.
AMD has made a conscious security choice : check rights as soon as possible, because that's what is the most security sensible stuff to do, even if it means taking a tiny performance hit because you need to make more checks on more potential branches. It's more correct this way.

AMD hasn't specifically planned the Meltdown exploit ahead of time, but they have taken the formally correct way to handle security, and it has payed in the long term (the CPU didn't end up affected once Meltdown was discovered) even if it did take a small performance hit in the short term (didn't benefit from the tiny performance increase that Intel did).

Again, due to Meltdown exploit Intel has broken fundamental tenet of memory protection. (Which just happened to not have been made clearly visible until recently, because nobody though about this specific timing exploit. But this has been "at risk" since the first Pentiums whose speculative execution was allow to go past security checks).

The Spectre exploits, of which one is also affecting AMD CPUs is in an entirely different league.
Whereas Meltdown on Intel CPUs goes across limits that should have been held by memory protection,
nothing in Spectre exploit is accessing something that the exploited application didn't have already access to.

It's simply a way for getting around some checks that might be in the way.
i.e.: that application might be making checks to array boundaries, before accessing them.
Due to speculative execution, the check that controls if we're not accessing out of bound might not have finished yet, and yet the actual invalid read might be in the pipeline already.
I doesn't give you sudden access to things that you shouldn't have access to. It just gives a way around some type of safety checks that might exist in the code you're trying to abuse.

It's a bit exotic and has some air of novelty, because it uses the speculative execution of modern CPU for a change.
But fundamentally it's a timing side-channel, not much different than other timing attacks done for quite some time (even remotely), hence the big work against data-dependent jumps in cryptography code.

And although it does open a couple of opportunity, the big deal isn't that much in the exploit itself.

Mostly, it's a big slap in the face of all "rust-troll" who come trumpeting for array limits checks whenever there's a buffer overflow exploit:
Memory access check should lift any responsibility from writing stupid code.

Yes, to bad that some of the checks can be slightly by passed, but:
- Why the fuck are you enabling non-standard kernel option to enable user-supplied JITed byte-code in the kernel ? User-supplied stuff in-kernel, what could possibly go wrong ?
- Is keeping sensitive stuff, like the storage of the password manager, and dangerous stuff, like execution remotely-provided javascript, in the same process a reasonable stuff to do ?

The k