All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Critical: CPU microarchitecture attack vector (affecting Hyper-Threading Architectures)
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 expiredFix
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
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.
Comments
It's not as severe as people might think / researches make it to be.
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.
It actually is. And I imagine we will have another run of reboots to correct this flaw.
As per zdnet:
Disclaimer: I have not yet run the PoC, will do this weekend on a virtualized environment.
I just explained why it isn't.
-
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?
ˆ just so we're clear on terms.
HT is just an implementation of SMT, not a separate thing.
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.
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.
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.
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.
We got plenty of nerds in LET!
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.
But no women.
We do have a few.
The only real woman I know of on LET is from Hetzner.
All others are men pretending to be women.
That is an entirely valid point.
I'm with @FHR who unlike OP at least understands the basic points.
What I see is
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.
@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.
Just because they refused your advances doesn't a woman make. Self esteem, perhaps.
A different perspective (aligned with positions expressed by @FHR btw) :