Critical: CPU microarchitecture attack vector (affecting Hyper-Threading Architectures)

MikePT

Howdy Folks,

We recently discovered a new CPU microarchitecture attack vector. The
nature of the leakage is due to execution engine sharing on SMT (e.g.
Hyper-Threading) architectures. More specifically, we detect port
contention to construct a timing side channel to exfiltrate
information from processes running in parallel on the same physical
core. Report is below.

Thanks for reading!

BBB

Report

We steal an OpenSSL (<= 1.1.0h) P-384 private key from a TLS server
using this new side-channel vector. It is a local attack in the sense
that the malicious process must be running on the same physical core
as the victim (an OpenSSL-powered TLS server in this case).

Affected hardware

SMT/Hyper-Threading architectures (verified on Skylake and Kaby Lake)

Affected software

OpenSSL <= 1.1.0h (but in general, software that has secret dependent
control flow at any granularity; this particular application is a
known vulnerability since 2009 only recently fixed)

Ubuntu 18.04 (again, it is really a hardware issue, but anyway this
distro is where we ran our experiments)

Classification and rating

Tracked by CVE-2018-5407.

CWE wise, I would label it like

CWE-208: Information Exposure Through Timing Discrepancy

At a very high level (e.g. CVSS string), it is similar to this CVE:

https://nvd.nist.gov/vuln/detail/CVE-2005-0109

But the underlying uarch component is totally different. Our attack
has nothing to do with the memory subsystem or caching, and that CVE
is specifically for data caching (e.g. some fixes for CVE-2005-0109 do
not address this new attack vector at all).

Disclosure timeline

01 Oct 2018: Notified Intel Security
26 Oct 2018: Notified openssl-security
26 Oct 2018: Notified CERT-FI
26 Oct 2018: Notified oss-security distros list
01 Nov 2018: Embargo expired

Fix

Disable SMT/Hyper-Threading in the bios

Upgrade to OpenSSL 1.1.1 (or >= 1.1.0i if you are looking for patches)

Credit

Billy Bob Brumley, Cesar Pereida Garcia, Sohaib ul Hassan, Nicola
Tuveri (Tampere University of Technology, Finland)
Alejandro Cabrera Aldaya (Universidad Tecnologica de la Habana CUJAE, Cuba)

Refs

https://marc.info/?l=openbsd-cvs&m=152943660103446
https://marc.info/?l=openbsd-tech&m=153504937925732

Source

Recommended action:

Disable SMT/Hyper-Threading in the bios

Upgrade to OpenSSL 1.1.1 (or >= 1.1.0i if you are looking for patches)

POC / exploit software has been hidden from this thread.

Additional intel: https://www.zdnet.com/article/intel-cpus-impacted-by-new-portsmash-side-channel-vulnerability/

Update: Intel has already silently issued updates. Researchers think this also affects AMD Architectures.

FHR

It's not as severe as people might think / researches make it to be.

• It requires disabled SpeedStep and Turbo Boost. Since it's a timing attack, any minuscule frequency changes are going to make it useless.

• The collector (or "spy" as they call it) must be running on the same physical core, but different logical one than the victim.
  This might seem easy, but it's actually really really hard to pull of in a shared VM environment, unless the host uses CPU pinning. KVM will evenly distribute the load (vCores) between all available cores according to their momentary load.
  This means that while the victim and "spy" can be on the same node in one moment, a second later they might even be on different physical CPUs.

• Since this is a timing attack, I would be surprised if this worked outside the lab - in a normal environment, you'll have lots of things loading the CPU on the node (e.g. mdraid, monitoring, hypervisor itself), which make any timing analysis highly unreliable.

All in all, in my opinion, this attack is garbage in the real world.

MikePT

It actually is. And I imagine we will have another run of reboots to correct this flaw.

As per zdnet:

The PoC steals an OpenSSL (<= 1.1.0h) P-384
private key from a TLS server by successfully exploiting PortSmash, but the attack can be modified to target any type of data.

The PortSmash PoC also requires malicious code to be running on the same physical core as the victim, but this isn't such a big hurdle for attackers.

"IaaS [Infrastructure-as-a-Service] is one scenario to make it more 'remote'," Brumley told ZDNet. "There, attackers would try to co-locate VMs with victims to end up running the exploit on the same physical core as the victim, but different logical core."

"[PortSmash] definitely does not need root privileges," he said "Just user space."

Disclaimer: I have not yet run the PoC, will do this weekend on a virtualized environment.

FHR

@MikePT said:
I actually think it is. And I imagine we will have another run of reboots to correct this flaw.

As per zdnet:

"IaaS [Infrastructure-as-a-Service] is one scenario to make it more 'remote'," Brumley told ZDNet. "There, attackers would try to co-locate VMs with victims to end up running the exploit on the same physical core as the victim, but different logical core."

"[PortSmash] definitely does not need root privileges," he said "Just user space."

I just explained why it isn't.

FHR said: The collector (or "spy" as they call it) must be running on the same physical core, but different logical one than the victim.
This might seem easy, but it's actually really really hard to pull of in a shared VM environment, unless the host uses CPU pinning. KVM will evenly distribute the load (vCores) between all available cores according to their momentary load.
This means that while the victim and "spy" can be on the same node in one moment, a second later they might even be on different physical CPUs.

-

FHR said: in a normal environment, you'll have lots of things loading the CPU on the node (e.g. mdraid, monitoring, hypervisor itself), which make any timing analysis highly unreliable.

MikePT

You can target the attack. You arent seeing its full potential.

The PoC steals an OpenSSL (<= 1.1.0h) P-384
private key from a TLS server by successfully exploiting PortSmash, but the attack can be modified to target any type of data.

FHR

@MikePT said:
You can target the attack. You arent seeing its full potential.

I'm looking at it from the perspective of cloud provider - which means at the perspective of real world risk, not a carefully crafted scenario in a lab.

I'm not saying this attack is not possible, I'm saying you can't really pull this off in
the real world.

MikePT

@FHR said:

@MikePT said:
You can target the attack. You arent seeing its full potential.

I'm looking at it from the perspective of cloud provider - which means at the perspective of real world risk, not a carefully crafted scenario in a lab.

I'm not saying this attack is not possible, I'm saying you can't really pull this off in
the real world.

You can definitely pull this off in real world. SMT and HT is what allows this. You are confusing virtual cores assigned to physical cores. Forget virtualization there. As long as its in the same physical CPU, its dangerous. I guess Intel patching this already makes it serious enough?

FHR

• Physical core - real core of the CPU. 4C/8T CPU = 4 cores.
• Logical core - HT core (thread) of the CPU. 4C/8T CPU = 8 cores (threads)
• vCore - A virtual core of a virtual machine.
  ˆ just so we're clear on terms.

@MikePT said:
You can definitely pull this off in real world. SMT and HT is what allows this.

HT is just an implementation of SMT, not a separate thing.

You are confusing virtual cores assigned to physical cores. Forget virtualization there. As long as its in the same physical CPU, its dangerous.

That's false. The research data clearly states that the attacker and victim HAVE TO be on the same physical core. Let me explain: If I have a 4C/8T chip with enabled hyperthreading, I'm going to see cores numbered as "0 1 2 3 4 5 6 7" from the OS. If the victim is running on core #0, the attacker has to listen core #1 in order to get data.
If the victim was on core #2, the attacker has to listen on core #3 etc…
Imagine that the real core and logical core form a pair.

Now - the article specifically mentions virtualization. And I'm saying KVM scheduler maps vCores to logical cores pretty much randomly (dynamically) unless you do CPU pinning (map vCore to a logical core in a fixed way manually).

Finally let me give an example: you've got 30 virtual machines on a 4C/8T machine.
1 of these VMs is the attacker and 1 is a victim. Even if both somehow ended up on the correct core combination (e.g. victim on core #0 and attacker on core #1), there would be enough noise from the other VMs that this attack wouldn't produce clear data.

Add in Turbo Boost/frequency scaling that is usually enabled if available and the attacker will get zero useful data.

I guess Intel patching this already makes it serious enough?

Well yeah, because it's a general practice to patch ANY vulnerability, however improbable it might be to use.

If I (hypothetically) proved that Intel CPUs crap out while you are dancing around them naked at full moon, Intel would fix it as well.

deank

This is like how a nerd explains that he can seduce women in dating games.

Alas, in real world environment, the nerd can't get any.

MikePT

@FHR said:

• Physical core - real core of the CPU. 4C/8T CPU = 4 cores.
• Logical core - HT core (thread) of the CPU. 4C/8T CPU = 8 cores (threads)
• vCore - A virtual core of a virtual machine.
  ˆ just so we're clear on terms.

@MikePT said:
You can definitely pull this off in real world. SMT and HT is what allows this.

HT is just an implementation of SMT, not a separate thing.

You are confusing virtual cores assigned to physical cores. Forget virtualization there. As long as its in the same physical CPU, its dangerous.

That's false. The research data clearly states that the attacker and victim HAVE TO be on the same physical core. Let me explain: If I have a 4C/8T chip with enabled hyperthreading, I'm going to see cores numbered as "0 1 2 3 4 5 6 7" from the OS. If the victim is running on core #0, the attacker has to listen core #1 in order to get data.
If the victim was on core #2, the attacker has to listen on core #3 etc…
Imagine that the real core and logical core form a pair.

Now - the article specifically mentions virtualization. And I'm saying KVM scheduler maps vCores to logical cores pretty much randomly (dynamically) unless you do CPU pinning (map vCore to a logical core in a fixed way manually).

Finally let me give an example: you've got 30 virtual machines on a 4C/8T machine.
1 of these VMs is the attacker and 1 is a victim. Even if both somehow ended up on the correct core combination (e.g. victim on core #0 and attacker on core #1), there would be enough noise from the other VMs that this attack wouldn't produce clear data.

Add in Turbo Boost/frequency scaling that is usually enabled if available and the attacker will get zero useful data.

I guess Intel patching this already makes it serious enough?

Well yeah, because it's a general practice to patch ANY vulnerability, however improbable it might be to use.

If I (hypothetically) proved that Intel CPUs crap out while you are dancing around them naked at full moon, Intel would fix it as well.

Last part was funny as hell!
I understand it may not be easy and its not likely to happen. Thing is, there is always a chance. OpenBSD for instance just decided to disable HT in full for another reported vulnerability (not this one tho).

This requires some advanced knowledge to investigate much further but I will run their PoC to see what happens. Curious if it'll work on AMD based CPUs.

MikePT

@deank said:
This is like how a nerd explains that he can seduce women in dating games.

Alas, in real world environment, the nerd can't get any.

We got plenty of nerds in LET!

joepie91

FHR said: It requires disabled SpeedStep and Turbo Boost. Since it's a timing attack, any minuscule frequency changes are going to make it useless.

I wouldn't be so sure. This same kind of argument made the rounds for a long time about timing attacks on password/key comparisons over a network. And then, whoops, it turned out that you could carry out timing attacks over a real-world network connection after all. Timing attacks and their viability aren't as well-understood as people like to believe...

And many real-world attacks actually consist of multiple vectors combined together; it's not unrealistic that somebody would find eg. a way to lock the CPU at a particular frequency. Such a thing would look innocent in and of itself, but combined with this seemingly-'garbage' attack, you'd suddenly have a viable attack vector.

stefeman

@MikePT said:

@deank said:
This is like how a nerd explains that he can seduce women in dating games.

Alas, in real world environment, the nerd can't get any.

We got plenty of nerds in LET!

But no women.

MikePT

@stefeman said:

@MikePT said:

@deank said:
This is like how a nerd explains that he can seduce women in dating games.

Alas, in real world environment, the nerd can't get any.

We got plenty of nerds in LET!

But no women.

We do have a few.

deank

The only real woman I know of on LET is from Hetzner.

All others are men pretending to be women.

FHR

@joepie91 said:

FHR said: It requires disabled SpeedStep and Turbo Boost. Since it's a timing attack, any minuscule frequency changes are going to make it useless.

I wouldn't be so sure. This same kind of argument made the rounds for a long time about timing attacks on password/key comparisons over a network. And then, whoops, it turned out that you could carry out timing attacks over a real-world network connection after all. Timing attacks and their viability aren't as well-understood as people like to believe...

And many real-world attacks actually consist of multiple vectors combined together; it's not unrealistic that somebody would find eg. a way to lock the CPU at a particular frequency. Such a thing would look innocent in and of itself, but combined with this seemingly-'garbage' attack, you'd suddenly have a viable attack vector.

That is an entirely valid point.

jsg

I'm with @FHR who unlike OP at least understands the basic points.

What I see is

• researchers with a grant needing to come up with some results, something, anything
• a well known general magazine lacking however any weight in the field of security research. Accordingly that magazine pretty much repeats what the researchers feed (incl. the image btw).
• a PoC with an impressive sounding result of the attack ("P-384 key!")
• an additional layer of largely unrelated but frightening and (supposedly) impressive quotes by e.g. OpenBSD core people (Hint: If this extra layer is needed we know that the story itself is a bit meager...)

Technically I see 1 interesting point: They use port contention. That's not really new per se but it's interesting in the context of an attack vector and it is indeed quite different from the Spectre/Meltdown group. I'll repeat that because it's important: This attack is not "yet another variant of S/M". It's different.
Btw, the "we don't need root" stems from that particular approach as every piece of code needs port access.

Simple attack summary:

It's a side channel attack. Which typically translates to needing many runs and a tightly controlled context (e.g. stable frequency, no speedstep or similar).

Note that the real world impact is pretty much insignificant. Reasons: Not only does the attack need to be on the same core as the victim but the victim also needs to be present at all which is quite a bit of lottery. Plus, as mentioned, one needs a tightly controlled context. There are also other factors like e.g. data size which is the real reason they chose to steal a P-384 (ECC) key (7 cache chunks) rather than an RSA key (50+ cache chunks).
Finally note that in a controlled lab environment not only can we control the victim but also any victim will do. In a real world attack we'd want to attack a certain chosen victim (which is typ. one of some thousand clients of a hoster). Plus we would need to get our VPS on the same node and the same core which is extremely unlikely considering that even the hosters don't know (or care) about the hypervisors housekeeping details. Also, again, keep in mind that most of the victims code is typically not SSL/TLS but hundred other things.

TL;DR: PortSmash is a "new" attack variant that is interesting from an academic perspective but is extremely unlikely to occur or to even be used in the wild, let alone successfully.

MikePT

@jsg, I am not a security researcher at all. I stand to what I said. Its still yet another vulnerability that can cause some damage.

CyberMonday

@deank said:
The only real woman I know of on LET is from Hetzner.

All others are men pretending to be women.

Just because they refused your advances doesn't a woman make. Self esteem, perhaps.

mfs

A different perspective (aligned with positions expressed by @FHR btw) :

https://twitter.com/cperciva/status/1058426846570672129