Stephan van Schaik - Alyssa Milburn
Sebastian Österlund - Pietro Frigo - Giorgi Maisuradze*
Kaveh Razavi - Herbert Bos - Cristiano Giuffrida
*
What can we still do as an attacker?
Meet Rogue In-flight Data Load or RIDL
A new class of speculative execution attacks
that knows no boundaries
Privilege levels are just a social construct
We can leak between hardware threads!
But can we leak across other security domains?
Yes, we can!
We leak from the kernel …
... across VMs …
... from the hypervisor …
... and from SGX enclaves!
We leak across all security domains!
Can we leak in the web browser?
Yes, we can!
We reproduced RIDL in Mozilla Firefox
⇒ No need for special instructions
We leak across security domains, and in the browser!
Memory addresses are a social construct too
Previous attacks show we can speculatively leak from addresses
Our mitigation efforts focus on isolating/masking addresses
Spectre: access out-of-bound addresses
Meltdown: leak kernel data from virtual addresses
Foreshadow: leak from physical address
Spectre: mask array index to limit address range
Meltdown: unmap kernel addresses from userspace
Foreshadow: invalidate physical address
Example
Problem: leak kernel data from virtual addresses
Solution: unmap kernel addresses
Previous attacks exploit addressing
Mitigation by isolating/masking addresses
RIDL does not depend on addressing:
⇒ Bypass all address-based security checks
⇒ Makes RIDL hard to mitigate
What CPUs does RIDL affect?
We bought Intel and AMD CPUs from almost every generation since 2008
... and sent the invoices to Herbert
RIDL works on all mainstream Intel CPUs since 2008
Intel announces Coffee Lake Refresh
In-silicon mitigations against Meltdown and Foreshadow
Let’s buy the Intel Core i9-9900K!
... and send another invoice to Herbert
We got it the day after we submitted the paper
===
RIDL works regardless of these in-silicon mitigations
We also tried to reproduce it on AMD
We also tried to reproduce it on AMD
RIDL does not affect AMD
But where are we actually leaking from?
Previous attacks had it easy, they leak from caches
Caches are well documented and well understood.
But RIDL does not leak from caches!
But what else is there to leak from?
There are other internal CPU buffers
Line Fill Buffers, Store Buffers and Load Ports
But there is more!
Uncached Memory
We can leak from various internal CPU buffers!
RIDL is a class of speculative execution attacks
also known as Micro-architectural Data Sampling
Let’s focus on one particular instance:
Line Fill Buffers
We first read the manuals
Some references to internal CPU buffers
But no further explanation
Where would you even start?
That’s why we started reading patents instead!
We read a lot of patents, and survived!
So today I can tell you a bit more about them
But wait, what are these
Line Fill Buffers?
They were never mentioned during
my Computer Architecture courses
but maybe I didn’t pay attention
Central buffer between execution units, L1d and L2 to improve memory throughput
Central buffer between execution units, L1d and L2 to improve memory throughput
Central buffer between execution units, L1d and L2 to improve memory throughput
Central buffer between execution units, L1d and L2 to improve memory throughput
Multiple roles:
Asynchronous memory requests
Load squashing
Write combining
Uncached memory
Multiple roles:
Asynchronous memory requests
Load squashing
Write combining
Uncached memory
CPU design: what to do on a cache miss?
Send out memory request
Wait for completion
Blocks other loads/stores
Solution: keep track of address in LFB
Send out memory request
Allocate LFB entry
Store address in LFB
Serve other loads/stores
Pending request eventually completes
Solution: keep track of address in LFB
Send out memory request
Allocate LFB entry
Store address in LFB
Serve other loads/stores
Pending request eventually completes
Allocate LFB entry
May contain data from previous load
RIDL exploits this
Experiments in the paper
Experiments in the paper
Experiments in the paper
Conclusion: our primary RIDL instance leaks from Line Fill Buffers
How do we mount a RIDL attack?
Victim VM in the cloud
We get a VM on the same server
We make sure it is co-located
Victim VM runs an SSH server
How do we get data in flight?
We run an SSH client…
... that keeps connecting to the SSH server
The SSH server loads /etc/shadow
through LFB
The contents from /etc/shadow
are in flight
Now that the data is in flight, we want to leak it
We run our RIDL program on our server…
...which leaks the data from the LFB
What does this program look like?
RIDL is like drinking from a fire hose
You just get whatever data is in flight!
How can we filter data?
We want to leak from /etc/shadow
First line /etc/shadow
is for root
Starts with "root:"
Use prefix matching:
Match ⇒ we learn a new byte
No Match ⇒ discard
More examples in the paper:
Leaking internal CPU data (e.g. page tables)
Arbitrary kernel read
Leaking in the browser
Same-thread:
verw
overwrite all buffers
Special Assembly snippets
Cross-thread:
Complex scheduling and synchronization
Same-thread:
verw
overwrite all buffers
Special Assembly snippets
Cross-thread:
Complex scheduling and synchronization
Disable Intel Hyper-Threading®
Disclosure process
We wrote a tool to verify your system:
Spectre and Meltdown, just one mistake?
New class of speculative execution attacks
Many more buffers other than caches to leak from
Does not rely on addresses ⇒ hard to mitigate
Across security domains, and in the browser
Spectre and Meltdown, just one mistake?
New class of speculative execution attacks
Many more buffers other than caches to leak from
Does not rely on addresses ⇒ hard to mitigate
Across security domains, and in the browser