software-based microarchitectural attacks · attacks and their mitigations [36, 43] are outside the...
TRANSCRIPT
Software-based Microarchitectural Attacks
Daniel Gruss
July 8, 2018
Graz University of Technology
1 Daniel Gruss — Graz University of Technology
Trusted Execution Environment www.tugraz.at
Application
Untrusted part
Operating System
2 Daniel Gruss — Graz University of Technology
Trusted Execution Environment www.tugraz.at
Application
Untrusted part
Create Enclave
Operating System
2 Daniel Gruss — Graz University of Technology
Trusted Execution Environment www.tugraz.at
Application
Trusted part
Cal
lG
ate
Untrusted part
Create Enclave
Trusted Fnc.
Operating System
2 Daniel Gruss — Graz University of Technology
Trusted Execution Environment www.tugraz.at
Application
Trusted part
Cal
lG
ate
Untrusted part
Create Enclave
Call Trusted Fnc.
Trusted Fnc.
Operating System
2 Daniel Gruss — Graz University of Technology
Trusted Execution Environment www.tugraz.at
Application
Trusted part
Cal
lG
ate
Untrusted part
Create Enclave
Call Trusted Fnc.
Trusted Fnc.
Operating System
2 Daniel Gruss — Graz University of Technology
Trusted Execution Environment www.tugraz.at
Application
Trusted part
Cal
lG
ate
Untrusted part
Create Enclave
Call Trusted Fnc.
Trusted Fnc.
Operating System
2 Daniel Gruss — Graz University of Technology
Trusted Execution Environment www.tugraz.at
Application
Trusted part
Cal
lG
ate
Untrusted part
Create Enclave
Call Trusted Fnc.
Trusted Fnc.
Return
Operating System
2 Daniel Gruss — Graz University of Technology
Trusted Execution Environment www.tugraz.at
Application
Trusted part
Cal
lG
ate
Untrusted part
Create Enclave
Call Trusted Fnc.
Trusted Fnc.
Return
Operating System
2 Daniel Gruss — Graz University of Technology
Trusted Execution Environment www.tugraz.at
Application
Trusted part
Cal
lG
ate
Untrusted part
Create Enclave
Call Trusted Fnc.
. . .
Trusted Fnc.
Return
Operating System
2 Daniel Gruss — Graz University of Technology
Trusted Execution Environment www.tugraz.at
Application
Trusted part
Cal
lG
ate
Untrusted part
Create Enclave
Call Trusted Fnc.
. . .
Trusted Fnc.
Return
Operating System
2 Daniel Gruss — Graz University of Technology
Stealing Bitcoins? www.tugraz.at
SGX
3 Daniel Gruss — Graz University of Technology
Stealing Bitcoins? www.tugraz.at
SGX
3 Daniel Gruss — Graz University of Technology
Stealing Bitcoins? www.tugraz.at
SGX
3 Daniel Gruss — Graz University of Technology
Stealing Bitcoins? www.tugraz.at
SGX
3 Daniel Gruss — Graz University of Technology
Stealing Bitcoins? www.tugraz.at
SGX
3 Daniel Gruss — Graz University of Technology
Stealing Bitcoins? www.tugraz.at
SGX
3 Daniel Gruss — Graz University of Technology
Intel SGX Developer Guide www.tugraz.at
Protection from Side-Channel Attacks
Intel SGX does not provide explicit protection from side-channel attacks. It is the
enclave developer’s responsibility to address side-channel attack concerns.
4 Daniel Gruss — Graz University of Technology
Intel SGX Developer Guide www.tugraz.at
Protection from Side-Channel Attacks
Intel SGX does not provide explicit protection from side-channel attacks. It is the
enclave developer’s responsibility to address side-channel attack concerns.
4 Daniel Gruss — Graz University of Technology
Intel SGX Developer Guide www.tugraz.at
Protection from Side-Channel Attacks
Intel SGX does not provide explicit protection from side-channel attacks.
It is the
enclave developer’s responsibility to address side-channel attack concerns.
4 Daniel Gruss — Graz University of Technology
Intel SGX Developer Guide www.tugraz.at
Protection from Side-Channel Attacks
Intel SGX does not provide explicit protection from side-channel attacks. It is the
enclave developer’s responsibility to address side-channel attack concerns.
4 Daniel Gruss — Graz University of Technology
SGX Wallets www.tugraz.at
• Ledger SGX Enclave for blockchain applications
• BitPay Copay Bitcoin wallet
• Teechain payment channel using SGX
Teechain
[...] We assume the TEE guarantees to hold and do not
consider side-channel attacks [5, 35, 46] on the TEE. Such
attacks and their mitigations [36, 43] are outside the scope of
this work. [...]
5 Daniel Gruss — Graz University of Technology
SGX Wallets www.tugraz.at
• Ledger SGX Enclave for blockchain applications
• BitPay Copay Bitcoin wallet
• Teechain payment channel using SGX
Teechain
[...] We assume the TEE guarantees to hold
and do not
consider side-channel attacks [5, 35, 46] on the TEE. Such
attacks and their mitigations [36, 43] are outside the scope of
this work. [...]
5 Daniel Gruss — Graz University of Technology
SGX Wallets www.tugraz.at
• Ledger SGX Enclave for blockchain applications
• BitPay Copay Bitcoin wallet
• Teechain payment channel using SGX
Teechain
[...] We assume the TEE guarantees to hold and do not
consider side-channel attacks [5, 35, 46] on the TEE.
Such
attacks and their mitigations [36, 43] are outside the scope of
this work. [...]
5 Daniel Gruss — Graz University of Technology
SGX Wallets www.tugraz.at
• Ledger SGX Enclave for blockchain applications
• BitPay Copay Bitcoin wallet
• Teechain payment channel using SGX
Teechain
[...] We assume the TEE guarantees to hold and do not
consider side-channel attacks [5, 35, 46] on the TEE. Such
attacks and their mitigations [36, 43] are outside the scope of
this work. [...]
5 Daniel Gruss — Graz University of Technology
Attacking a weak RSA implementation inside SGX www.tugraz.at
Raw Prime+Probe trace...1
1M. Schwarz, D. Gruss, S. Weiser, C. Maurice, and S. Mangard. Malware Guard Extension: Using
SGX to Conceal Cache Attacks. In: DIMVA. 2017.
6 Daniel Gruss — Graz University of Technology
Attacking a weak RSA implementation inside SGX www.tugraz.at
...processed with a simple moving average...2
2M. Schwarz, D. Gruss, S. Weiser, C. Maurice, and S. Mangard. Malware Guard Extension: Using
SGX to Conceal Cache Attacks. In: DIMVA. 2017.
7 Daniel Gruss — Graz University of Technology
Attacking a weak RSA implementation inside SGX www.tugraz.at
...allows to clearly see the bits of the exponent3
1 1 1 00 1 1 1 01 1 1 00000001 000 1 0 1 00 1 1 00 1 1 01 1 1 1 1 0 1 1 1 1 0 1 000 1 00 1 1 1 0 1 000 1 1 1 0000 1 1 1
3M. Schwarz, D. Gruss, S. Weiser, C. Maurice, and S. Mangard. Malware Guard Extension: Using
SGX to Conceal Cache Attacks. In: DIMVA. 2017.
8 Daniel Gruss — Graz University of Technology
Microarchitectural Attacks - Threat Model www.tugraz.at
• Usually no physical access
• Local code
• Co-located code
• Different meanings of “remote”
1. Attacker controls code in browser sandbox (e.g., [Ore+15;
GMM16])
2. Attacker cannot control any code on the system
9 Daniel Gruss — Graz University of Technology
Microarchitectural Attacks - Threat Model www.tugraz.at
• Usually no physical access
• Local code
• Co-located code
• Different meanings of “remote”
1. Attacker controls code in browser sandbox (e.g., [Ore+15;
GMM16])
2. Attacker cannot control any code on the system
9 Daniel Gruss — Graz University of Technology
Microarchitectural Attacks - Threat Model www.tugraz.at
• Usually no physical access
• Local code
• Co-located code
• Different meanings of “remote”
1. Attacker controls code in browser sandbox (e.g., [Ore+15;
GMM16])
2. Attacker cannot control any code on the system
9 Daniel Gruss — Graz University of Technology
Microarchitectural Attacks - Threat Model www.tugraz.at
• Usually no physical access
• Local code
• Co-located code
• Different meanings of “remote”
1. Attacker controls code in browser sandbox (e.g., [Ore+15;
GMM16])
2. Attacker cannot control any code on the system
9 Daniel Gruss — Graz University of Technology
Microarchitectural Attacks - Threat Model www.tugraz.at
• Usually no physical access
• Local code
• Co-located code
• Different meanings of “remote”
1. Attacker controls code in browser sandbox (e.g., [Ore+15;
GMM16])
2. Attacker cannot control any code on the system
9 Daniel Gruss — Graz University of Technology
Microarchitectural Attacks - Threat Model www.tugraz.at
• Usually no physical access
• Local code
• Co-located code
• Different meanings of “remote”
1. Attacker controls code in browser sandbox (e.g., [Ore+15;
GMM16])
2. Attacker cannot control any code on the system
9 Daniel Gruss — Graz University of Technology
Microarchitectural Attacks - Threat Model www.tugraz.at
• Usually no physical access
• Local code
• Co-located code
• Different meanings of “remote”
1. Attacker controls code in browser sandbox (e.g., [Ore+15;
GMM16])
2. Attacker cannot control any code on the system
9 Daniel Gruss — Graz University of Technology
1337 4242
Revolutionary concept!
Store your food at home, never go to the grocery store during cooking.
Can store ALL kinds of food.
ONLY TODAY INSTEAD OF $1,300
ORDER VIA PHONE: +555 12345
CPU Cache www.tugraz.at
10 Daniel Gruss — Graz University of Technology
CPU Cache www.tugraz.at
10 Daniel Gruss — Graz University of Technology
CPU Cache www.tugraz.at
10 Daniel Gruss — Graz University of Technology
CPU Cache www.tugraz.at
10 Daniel Gruss — Graz University of Technology
CPU Cache www.tugraz.at
10 Daniel Gruss — Graz University of Technology
CPU Cache www.tugraz.at
10 Daniel Gruss — Graz University of Technology
CPU Cache www.tugraz.at
10 Daniel Gruss — Graz University of Technology
CPU Cache www.tugraz.at
10 Daniel Gruss — Graz University of Technology
Flush+Reload www.tugraz.at
11 Daniel Gruss — Graz University of Technology
Flush+Reload www.tugraz.at
11 Daniel Gruss — Graz University of Technology
Flush+Reload www.tugraz.at
11 Daniel Gruss — Graz University of Technology
Flush+Reload www.tugraz.at
11 Daniel Gruss — Graz University of Technology
Flush+Reload www.tugraz.at
11 Daniel Gruss — Graz University of Technology
Flush+Reload www.tugraz.at
11 Daniel Gruss — Graz University of Technology
Flush+Reload www.tugraz.at
11 Daniel Gruss — Graz University of Technology
Flush+Reload www.tugraz.at
11 Daniel Gruss — Graz University of Technology
Temporal Component: Timestamps www.tugraz.at
Physical Side Channels
• theoretical maximum accuracy of 5.4 · 10−44s
• feasible today: 850 · 10−21s
Microarchitectural Attacks
• often around nanoseconds
• sometimes much lower
12 Daniel Gruss — Graz University of Technology
Temporal Component: Timestamps www.tugraz.at
Physical Side Channels
• theoretical maximum accuracy of 5.4 · 10−44s
• feasible today: 850 · 10−21s
Microarchitectural Attacks
• often around nanoseconds
• sometimes much lower
12 Daniel Gruss — Graz University of Technology
Temporal Component: Timestamps www.tugraz.at
Physical Side Channels
• theoretical maximum accuracy of 5.4 · 10−44s
• feasible today: 850 · 10−21s
Microarchitectural Attacks
• often around nanoseconds
• sometimes much lower
12 Daniel Gruss — Graz University of Technology
Temporal Component: Timestamps www.tugraz.at
Physical Side Channels
• theoretical maximum accuracy of 5.4 · 10−44s
• feasible today: 850 · 10−21s
Microarchitectural Attacks
• often around nanoseconds
• sometimes much lower
12 Daniel Gruss — Graz University of Technology
Temporal Component: Timestamps www.tugraz.at
Physical Side Channels
• theoretical maximum accuracy of 5.4 · 10−44s
• feasible today: 850 · 10−21s
Microarchitectural Attacks
• often around nanoseconds
• sometimes much lower
12 Daniel Gruss — Graz University of Technology
Temporal Component: Timestamps www.tugraz.at
Physical Side Channels
• theoretical maximum accuracy of 5.4 · 10−44s
• feasible today: 850 · 10−21s
Microarchitectural Attacks
• often around nanoseconds
• sometimes much lower
12 Daniel Gruss — Graz University of Technology
Temporal Component: Sampling Rate www.tugraz.at
Physical Side Channels
• in the range of multiple GHz
Microarchitectural Attacks
• usually varying frequency (depending on the attack)
• between a few ns (< 1 GHz) and multiple seconds (< 1 Hz) (or
even worse)
• strongly dependent on the specific attack
• device under test = measurement device
• observer effect
13 Daniel Gruss — Graz University of Technology
Temporal Component: Sampling Rate www.tugraz.at
Physical Side Channels
• in the range of multiple GHz
Microarchitectural Attacks
• usually varying frequency (depending on the attack)
• between a few ns (< 1 GHz) and multiple seconds (< 1 Hz) (or
even worse)
• strongly dependent on the specific attack
• device under test = measurement device
• observer effect
13 Daniel Gruss — Graz University of Technology
Temporal Component: Sampling Rate www.tugraz.at
Physical Side Channels
• in the range of multiple GHz
Microarchitectural Attacks
• usually varying frequency (depending on the attack)
• between a few ns (< 1 GHz) and multiple seconds (< 1 Hz) (or
even worse)
• strongly dependent on the specific attack
• device under test = measurement device
• observer effect
13 Daniel Gruss — Graz University of Technology
Temporal Component: Sampling Rate www.tugraz.at
Physical Side Channels
• in the range of multiple GHz
Microarchitectural Attacks
• usually varying frequency (depending on the attack)
• between a few ns (< 1 GHz) and multiple seconds (< 1 Hz) (or
even worse)
• strongly dependent on the specific attack
• device under test = measurement device
• observer effect
13 Daniel Gruss — Graz University of Technology
Temporal Component: Sampling Rate www.tugraz.at
Physical Side Channels
• in the range of multiple GHz
Microarchitectural Attacks
• usually varying frequency (depending on the attack)
• between a few ns (< 1 GHz) and multiple seconds (< 1 Hz) (or
even worse)
• strongly dependent on the specific attack
• device under test = measurement device
• observer effect
13 Daniel Gruss — Graz University of Technology
Temporal Component: Sampling Rate www.tugraz.at
Physical Side Channels
• in the range of multiple GHz
Microarchitectural Attacks
• usually varying frequency (depending on the attack)
• between a few ns (< 1 GHz) and multiple seconds (< 1 Hz) (or
even worse)
• strongly dependent on the specific attack
• device under test = measurement device
• observer effect
13 Daniel Gruss — Graz University of Technology
Temporal Component: Sampling Rate www.tugraz.at
Physical Side Channels
• in the range of multiple GHz
Microarchitectural Attacks
• usually varying frequency (depending on the attack)
• between a few ns (< 1 GHz) and multiple seconds (< 1 Hz) (or
even worse)
• strongly dependent on the specific attack
• device under test = measurement device
• observer effect
13 Daniel Gruss — Graz University of Technology
Temporal Component: Sampling Rate www.tugraz.at
Physical Side Channels
• in the range of multiple GHz
Microarchitectural Attacks
• usually varying frequency (depending on the attack)
• between a few ns (< 1 GHz) and multiple seconds (< 1 Hz) (or
even worse)
• strongly dependent on the specific attack
• device under test = measurement device
• observer effect
13 Daniel Gruss — Graz University of Technology
Microarchitectural Observer Effect www.tugraz.at
device under test = measurement device
• measuring time takes some time
• limits the resolution
• measuring cache hits/misses manipulates the cache state
• virtually all measurements are destructive
14 Daniel Gruss — Graz University of Technology
Measurement Noise www.tugraz.at
Flush+Reload has no noise except for:
• Race condition between attacker and victim (observer effect)
• Speculative execution
• Prefetching
• ...
→ Typically > 99.99% precision and recall
15 Daniel Gruss — Graz University of Technology
Measurement Noise www.tugraz.at
Flush+Reload has no noise except for:
• Race condition between attacker and victim (observer effect)
• Speculative execution
• Prefetching
• ...
→ Typically > 99.99% precision and recall
15 Daniel Gruss — Graz University of Technology
Measurement Noise www.tugraz.at
Flush+Reload has no noise except for:
• Race condition between attacker and victim (observer effect)
• Speculative execution
• Prefetching
• ...
→ Typically > 99.99% precision and recall
15 Daniel Gruss — Graz University of Technology
Measurement Noise www.tugraz.at
Flush+Reload has no noise except for:
• Race condition between attacker and victim (observer effect)
• Speculative execution
• Prefetching
• ...
→ Typically > 99.99% precision and recall
15 Daniel Gruss — Graz University of Technology
Measurement Noise www.tugraz.at
Flush+Reload has no noise except for:
• Race condition between attacker and victim (observer effect)
• Speculative execution
• Prefetching
• ...
→ Typically > 99.99% precision and recall
15 Daniel Gruss — Graz University of Technology
Measurement Noise www.tugraz.at
Flush+Reload has no noise except for:
• Race condition between attacker and victim (observer effect)
• Speculative execution
• Prefetching
• ...
→ Typically > 99.99% precision and recall
15 Daniel Gruss — Graz University of Technology
Measurement Noise www.tugraz.at
Flush+Reload has no noise except for:
• Race condition between attacker and victim (observer effect)
• Speculative execution
• Prefetching
• ...
→ Typically > 99.99% precision and recall
15 Daniel Gruss — Graz University of Technology
Measurement Noise www.tugraz.at
Flush+Reload has no noise except for:
• Race condition between attacker and victim (observer effect)
• Speculative execution
• Prefetching
• ...
→ Typically > 99.99% precision and recall
15 Daniel Gruss — Graz University of Technology
Measuring Processor Operations
Timing Measurements www.tugraz.at
• Very short timings
• rdtsc instruction: “cycle-accurate” timestamps
[...]
rdtsc
function()
rdtsc
[...]
16 Daniel Gruss — Graz University of Technology
What are we measuring? www.tugraz.at
• Do you measure what you think you measure?
• Out-of-order execution → what is really executed
rdtsc
function()
[...]
rdtsc
rdtsc
[...]
rdtsc
function()
rdtsc
rdtsc
function()
[...]
17 Daniel Gruss — Graz University of Technology
Accurate Microarchitecture Timing www.tugraz.at
• use pseudo-serializing instruction rdtscp (recent CPUs)
• and/or use serializing instructions like cpuid
• and/or use fences like mfence
Intel, How to Benchmark Code Execution Times on Intel IA-32 and IA-64 Instruction Set Architectures
White Paper, December 2010.
18 Daniel Gruss — Graz University of Technology
Accurate Microarchitecture Timing www.tugraz.at
• use pseudo-serializing instruction rdtscp (recent CPUs)
• and/or use serializing instructions like cpuid
• and/or use fences like mfence
Intel, How to Benchmark Code Execution Times on Intel IA-32 and IA-64 Instruction Set Architectures
White Paper, December 2010.
18 Daniel Gruss — Graz University of Technology
Accurate Microarchitecture Timing www.tugraz.at
• use pseudo-serializing instruction rdtscp (recent CPUs)
• and/or use serializing instructions like cpuid
• and/or use fences like mfence
Intel, How to Benchmark Code Execution Times on Intel IA-32 and IA-64 Instruction Set Architectures
White Paper, December 2010.
18 Daniel Gruss — Graz University of Technology
Accurate Microarchitecture Timing www.tugraz.at
• use pseudo-serializing instruction rdtscp (recent CPUs)
• and/or use serializing instructions like cpuid
• and/or use fences like mfence
Intel, How to Benchmark Code Execution Times on Intel IA-32 and IA-64 Instruction Set Architectures
White Paper, December 2010.
18 Daniel Gruss — Graz University of Technology
Memory Access Latency www.tugraz.at
50 100 150 200 250 300 350 400
101
104
107
Access time [CPU cycles]
Nu
mb
erof
acce
sses
Cache Hits
19 Daniel Gruss — Graz University of Technology
Memory Access Latency www.tugraz.at
50 100 150 200 250 300 350 400
101
104
107
Access time [CPU cycles]
Nu
mb
erof
acce
sses
Cache Hits Cache Misses
19 Daniel Gruss — Graz University of Technology
Temporal Component www.tugraz.at
• Flush+Reload had beautifully nice timings, right?
• Well... steps of 2-4 cycles
• only 35-70 steps between hits and misses
• On some devices only 1-2 steps!
20 Daniel Gruss — Graz University of Technology
Temporal Component www.tugraz.at
• Flush+Reload had beautifully nice timings, right?
• Well... steps of 2-4 cycles
• only 35-70 steps between hits and misses
• On some devices only 1-2 steps!
20 Daniel Gruss — Graz University of Technology
Temporal Component www.tugraz.at
• Flush+Reload had beautifully nice timings, right?
• Well... steps of 2-4 cycles
• only 35-70 steps between hits and misses
• On some devices only 1-2 steps!
20 Daniel Gruss — Graz University of Technology
Temporal Component www.tugraz.at
• Flush+Reload had beautifully nice timings, right?
• Well... steps of 2-4 cycles
• only 35-70 steps between hits and misses
• On some devices only 1-2 steps!
20 Daniel Gruss — Graz University of Technology
Temporal Component www.tugraz.at
• Flush+Reload had beautifully nice timings, right?
• Well... steps of 2-4 cycles
• only 35-70 steps between hits and misses
• On some devices only 1-2 steps!
20 Daniel Gruss — Graz University of Technology
Temporal Component www.tugraz.at
• Flush+Reload had beautifully nice timings, right?
• Well... steps of 2-4 cycles
• only 35-70 steps between hits and misses
• On some devices only 1-2 steps!
20 Daniel Gruss — Graz University of Technology
Temporal Component www.tugraz.at
• Flush+Reload had beautifully nice timings, right?
• Well... steps of 2-4 cycles
• only 35-70 steps between hits and misses
• On some devices only 1-2 steps!
20 Daniel Gruss — Graz University of Technology
Timer www.tugraz.at
• We can build our own timer [Lip+16; Sch+17]
• Start a thread that continuously increments a global variable
• The global variable is our timestamp
21 Daniel Gruss — Graz University of Technology
Timer www.tugraz.at
• We can build our own timer [Lip+16; Sch+17]
• Start a thread that continuously increments a global variable
• The global variable is our timestamp
21 Daniel Gruss — Graz University of Technology
Timer www.tugraz.at
• We can build our own timer [Lip+16; Sch+17]
• Start a thread that continuously increments a global variable
• The global variable is our timestamp
21 Daniel Gruss — Graz University of Technology
Self-built Timer www.tugraz.at
CPU cycles one increment takes
Optimized
Assembly
C
rdtsc 3
4.7
4.67
0.87
3 1 t imestamp = r d t s c ( ) ;
22 Daniel Gruss — Graz University of Technology
Self-built Timer www.tugraz.at
CPU cycles one increment takes
Optimized
Assembly
C
rdtsc 3
4.7
4.67
0.87
3 1 whi le (1 ) {2 t imestamp++;
3 }
22 Daniel Gruss — Graz University of Technology
Self-built Timer www.tugraz.at
CPU cycles one increment takes
Optimized
Assembly
C
rdtsc 3
4.7
4.67
0.87
3
4.7
22 Daniel Gruss — Graz University of Technology
Self-built Timer www.tugraz.at
CPU cycles one increment takes
Optimized
Assembly
C
rdtsc 3
4.7
4.67
0.87
3
4.7
1 mov ×tamp , %rcx
2 1 : i n c l (% rcx )
3 jmp 1b
22 Daniel Gruss — Graz University of Technology
Self-built Timer www.tugraz.at
CPU cycles one increment takes
Optimized
Assembly
C
rdtsc 3
4.7
4.67
0.87
3
4.7
4.67
22 Daniel Gruss — Graz University of Technology
Self-built Timer www.tugraz.at
CPU cycles one increment takes
Optimized
Assembly
C
rdtsc 3
4.7
4.67
0.87
3
4.7
4.67
1 mov ×tamp , %rcx
2 1 : i n c %rax
3 mov %rax , (% rcx )
4 jmp 1b
22 Daniel Gruss — Graz University of Technology
Self-built Timer www.tugraz.at
CPU cycles one increment takes
Optimized
Assembly
C
rdtsc 3
4.7
4.67
0.87
3
4.7
4.67
0.87
22 Daniel Gruss — Graz University of Technology
Spatial Component www.tugraz.at
• physical: different offsets on the chip
• microarchitectural:
• different microarchitectural elements
• more significant: huge virtual adress space
• 248 different virtual memory locations
• the location is often (part of) the secret
23 Daniel Gruss — Graz University of Technology
Spatial Component www.tugraz.at
• physical: different offsets on the chip
• microarchitectural:
• different microarchitectural elements
• more significant: huge virtual adress space
• 248 different virtual memory locations
• the location is often (part of) the secret
23 Daniel Gruss — Graz University of Technology
Spatial Component www.tugraz.at
• physical: different offsets on the chip
• microarchitectural:
• different microarchitectural elements
• more significant: huge virtual adress space
• 248 different virtual memory locations
• the location is often (part of) the secret
23 Daniel Gruss — Graz University of Technology
Spatial Component www.tugraz.at
• physical: different offsets on the chip
• microarchitectural:
• different microarchitectural elements
• more significant: huge virtual adress space
• 248 different virtual memory locations
• the location is often (part of) the secret
23 Daniel Gruss — Graz University of Technology
Spatial Component www.tugraz.at
• physical: different offsets on the chip
• microarchitectural:
• different microarchitectural elements
• more significant: huge virtual adress space
• 248 different virtual memory locations
• the location is often (part of) the secret
23 Daniel Gruss — Graz University of Technology
Spatial Component www.tugraz.at
• physical: different offsets on the chip
• microarchitectural:
• different microarchitectural elements
• more significant: huge virtual adress space
• 248 different virtual memory locations
• the location is often (part of) the secret
23 Daniel Gruss — Graz University of Technology
Spatial Component www.tugraz.at
• physical: different offsets on the chip
• microarchitectural:
• different microarchitectural elements
• more significant: huge virtual adress space
• 248 different virtual memory locations
• the location is often (part of) the secret
23 Daniel Gruss — Graz University of Technology
Spatial Component www.tugraz.at
• physical: different offsets on the chip
• microarchitectural:
• different microarchitectural elements
• more significant: huge virtual adress space
• 248 different virtual memory locations
• the location is often (part of) the secret
23 Daniel Gruss — Graz University of Technology
Spatial Component www.tugraz.at
• physical: different offsets on the chip
• microarchitectural:
• different microarchitectural elements
• more significant: huge virtual adress space
• 248 different virtual memory locations
• the location is often (part of) the secret
23 Daniel Gruss — Graz University of Technology
Cache Template Attack Demo
Cache Template4 www.tugraz.at
Address
Keyg h i j k l m n o p q r s t u v w x y z
0x7c6800x7c6c00x7c7000x7c7400x7c7800x7c7c00x7c8000x7c8400x7c8800x7c8c00x7c9000x7c9400x7c9800x7c9c00x7ca000x7cb800x7cc400x7cc800x7ccc00x7cd00
4D. Gruss, R. Spreitzer, and S. Mangard. Cache Template Attacks: Automating Attacks on Inclusive
Last-Level Caches. In: USENIX Security Symposium. 2015.
25 Daniel Gruss — Graz University of Technology
Page Cache www.tugraz.at
• Managed by operating system
• Buffers pages in RAM for faster accesses
• State of pages is tracked:
• No write access → clean → no write back
• Write access → dirty → write back
• Implemented by all major operating systems
26 Daniel Gruss — Graz University of Technology
Page Cache www.tugraz.at
• Managed by operating system
• Buffers pages in RAM for faster accesses
• State of pages is tracked:
• No write access → clean → no write back
• Write access → dirty → write back
• Implemented by all major operating systems
26 Daniel Gruss — Graz University of Technology
Page Cache www.tugraz.at
• Managed by operating system
• Buffers pages in RAM for faster accesses
• State of pages is tracked:
• No write access → clean → no write back
• Write access → dirty → write back
• Implemented by all major operating systems
26 Daniel Gruss — Graz University of Technology
Page Cache www.tugraz.at
• Managed by operating system
• Buffers pages in RAM for faster accesses
• State of pages is tracked:
• No write access → clean → no write back
• Write access → dirty → write back
• Implemented by all major operating systems
26 Daniel Gruss — Graz University of Technology
Page Cache www.tugraz.at
• Managed by operating system
• Buffers pages in RAM for faster accesses
• State of pages is tracked:
• No write access → clean → no write back
• Write access → dirty → write back
• Implemented by all major operating systems
26 Daniel Gruss — Graz University of Technology
Page Cache www.tugraz.at
• Managed by operating system
• Buffers pages in RAM for faster accesses
• State of pages is tracked:
• No write access → clean → no write back
• Write access → dirty → write back
• Implemented by all major operating systems
26 Daniel Gruss — Graz University of Technology
Page Cache Attacks www.tugraz.at
OS
Disk
Victim Attacker
Address space
foo.so#2foo.so#1
foo.so#3foo.so#4
eviction#2eviction#3eviction#4eviction#5
eviction#1
foo.so#1foo.so#2foo.so#3foo.so#4
Address space
RAM
page cache
27 Daniel Gruss — Graz University of Technology
Page Cache Attacks www.tugraz.at
OS
Disk
Victim Attacker
Address space
foo.so#2foo.so#1
foo.so#3foo.so#4
eviction#2eviction#3eviction#4eviction#5
eviction#1
foo.so#1foo.so#2foo.so#3foo.so#4
Address space
RAM
page cache
foo.so#2
faults
fetches foo.so#2
buffers foo.so#2
accesses
slow
28 Daniel Gruss — Graz University of Technology
Page Cache Attacks www.tugraz.at
OS
Disk
Victim Attacker
Address space
foo.so#2foo.so#1
foo.so#3foo.so#4
eviction#2eviction#3eviction#4eviction#5
eviction#1
foo.so#1foo.so#2foo.so#3foo.so#4
Address space
RAM
page cache
foo.so#2
29 Daniel Gruss — Graz University of Technology
Page Cache Attacks www.tugraz.at
OS
Disk
Victim Attacker
Address space
foo.so#2foo.so#1
foo.so#3foo.so#4
eviction#2eviction#3eviction#4eviction#5
eviction#1
foo.so#1foo.so#2foo.so#3foo.so#4
Address space
RAM
page cache
foo.so#2
accesses
fast
30 Daniel Gruss — Graz University of Technology
Page Cache Attacks www.tugraz.at
OS
Disk
Victim Attacker
Address space
foo.so#2foo.so#1
foo.so#3foo.so#4
eviction#2eviction#3eviction#4eviction#5
eviction#1
foo.so#1foo.so#2foo.so#3foo.so#4
Address space
RAM
page cache
foo.so#2
eviction#5
accessesfetches eviction#5
buffers eviction#5
faults
slow
31 Daniel Gruss — Graz University of Technology
Page Cache Attacks www.tugraz.at
OS
Disk
Victim Attacker
Address space
foo.so#2foo.so#1
foo.so#3foo.so#4
eviction#2eviction#3eviction#4eviction#5
eviction#1
foo.so#1foo.so#2foo.so#3foo.so#4
Address space
RAM
page cache
eviction#4foo.so#2
eviction#5
accessesfetches eviction#4
buffers eviction#4
faults
slow
32 Daniel Gruss — Graz University of Technology
Page Cache Attacks www.tugraz.at
OS
Disk
Victim Attacker
Address space
foo.so#2foo.so#1
foo.so#3foo.so#4
eviction#2eviction#3eviction#4eviction#5
eviction#1
foo.so#1foo.so#2foo.so#3foo.so#4
Address space
RAM
page cache
eviction#4foo.so#2
eviction#3
eviction#5
accessesfetches eviction#3
buffers eviction#3
faults
slow
33 Daniel Gruss — Graz University of Technology
Page Cache Attacks www.tugraz.at
OS
Disk
Victim Attacker
Address space
foo.so#2foo.so#1
foo.so#3foo.so#4
eviction#2eviction#3eviction#4eviction#5
eviction#1
foo.so#1foo.so#2foo.so#3foo.so#4
Address space
RAM
page cache
eviction#4foo.so#2
eviction#3eviction#2
eviction#5
accessesfetches eviction#2
buffers eviction#2
faults
slow
34 Daniel Gruss — Graz University of Technology
Page Cache Attacks www.tugraz.at
OS
Disk
Victim Attacker
Address space
foo.so#2foo.so#1
foo.so#3foo.so#4
eviction#2eviction#3eviction#4eviction#5
eviction#1
foo.so#1foo.so#2foo.so#3foo.so#4
Address space
RAM
page cache
eviction#4eviction#1eviction#3eviction#2
eviction#5
accessesfetches eviction#1
buffers eviction#1
faults
slow
35 Daniel Gruss — Graz University of Technology
Page Cache Attacks www.tugraz.at
OS
Disk
Victim Attacker
Address space
foo.so#2foo.so#1
foo.so#3foo.so#4
eviction#2eviction#3eviction#4eviction#5
eviction#1
foo.so#1foo.so#2foo.so#3foo.so#4
Address space
RAM
page cache
eviction#4eviction#1eviction#3eviction#2
eviction#5
36 Daniel Gruss — Graz University of Technology
Page Cache Attacks www.tugraz.at
OS
Disk
Victim Attacker
Address space
foo.so#2foo.so#1
foo.so#3foo.so#4
eviction#2eviction#3eviction#4eviction#5
eviction#1
foo.so#1foo.so#2foo.so#3foo.so#4
Address space
RAM
page cache
eviction#4eviction#1eviction#3eviction#2
foo.so#2
accessesfetches foo.so#2
buffers foo.so#2
faults
slow
37 Daniel Gruss — Graz University of Technology
Observe Page Cache State www.tugraz.at
1010 1
mincore (2.04µs)
• Takes virtual memory range, returns vector
• Indicates presence of queried pages in page cache
QueryWorkingSetEx (465.91 ns)
• Takes process handle + virtual memory address, returns struct
• Exposes attributes of queried page ...
• ... presence in working set
• ... number of working sets containing page (ShareCount)
38 Daniel Gruss — Graz University of Technology
Observe Page Cache State www.tugraz.at
1010 1
mincore (2.04µs)
• Takes virtual memory range, returns vector
• Indicates presence of queried pages in page cache
QueryWorkingSetEx (465.91 ns)
• Takes process handle + virtual memory address, returns struct
• Exposes attributes of queried page ...
• ... presence in working set
• ... number of working sets containing page (ShareCount)
38 Daniel Gruss — Graz University of Technology
Observe Page Cache State www.tugraz.at
1010 1
mincore (2.04µs)
• Takes virtual memory range, returns vector
• Indicates presence of queried pages in page cache
QueryWorkingSetEx (465.91 ns)
• Takes process handle + virtual memory address, returns struct
• Exposes attributes of queried page ...
• ... presence in working set
• ... number of working sets containing page (ShareCount)
38 Daniel Gruss — Graz University of Technology
Observe Page Cache State www.tugraz.at
1010 1
mincore (2.04µs)
• Takes virtual memory range, returns vector
• Indicates presence of queried pages in page cache
QueryWorkingSetEx (465.91 ns)
• Takes process handle + virtual memory address, returns struct
• Exposes attributes of queried page ...
• ... presence in working set
• ... number of working sets containing page (ShareCount)
38 Daniel Gruss — Graz University of Technology
Observe Page Cache State www.tugraz.at
1010 1
mincore (2.04µs)
• Takes virtual memory range, returns vector
• Indicates presence of queried pages in page cache
QueryWorkingSetEx (465.91 ns)
• Takes process handle + virtual memory address, returns struct
• Exposes attributes of queried page ...
• ... presence in working set
• ... number of working sets containing page (ShareCount)
38 Daniel Gruss — Graz University of Technology
Observe Page Cache State www.tugraz.at
1010 1
mincore (2.04µs)
• Takes virtual memory range, returns vector
• Indicates presence of queried pages in page cache
QueryWorkingSetEx (465.91 ns)
• Takes process handle + virtual memory address, returns struct
• Exposes attributes of queried page ...
• ... presence in working set
• ... number of working sets containing page (ShareCount)
38 Daniel Gruss — Graz University of Technology
Observe Page Cache State www.tugraz.at
1010 1
mincore (2.04µs)
• Takes virtual memory range, returns vector
• Indicates presence of queried pages in page cache
QueryWorkingSetEx (465.91 ns)
• Takes process handle + virtual memory address, returns struct
• Exposes attributes of queried page ...
• ... presence in working set
• ... number of working sets containing page (ShareCount)
38 Daniel Gruss — Graz University of Technology
Observe Page Cache State www.tugraz.at
1010 1
mincore (2.04µs)
• Takes virtual memory range, returns vector
• Indicates presence of queried pages in page cache
QueryWorkingSetEx (465.91 ns)
• Takes process handle + virtual memory address, returns struct
• Exposes attributes of queried page ...
• ... presence in working set
• ... number of working sets containing page (ShareCount)
38 Daniel Gruss — Graz University of Technology
Reset Page Cache State www.tugraz.at
• Necessary for detecting multiple accesses
• Bottleneck of side channel
• Linux: eviction (takes 149 ms)
• Windows: VirtualUnlock if possible (takes 17.69µs)
• Windows: SetProcessWorkingSetSize + eviction (takes
4.48 ms)
39 Daniel Gruss — Graz University of Technology
Reset Page Cache State www.tugraz.at
• Necessary for detecting multiple accesses
• Bottleneck of side channel
• Linux: eviction (takes 149 ms)
• Windows: VirtualUnlock if possible (takes 17.69µs)
• Windows: SetProcessWorkingSetSize + eviction (takes
4.48 ms)
39 Daniel Gruss — Graz University of Technology
Reset Page Cache State www.tugraz.at
• Necessary for detecting multiple accesses
• Bottleneck of side channel
• Linux: eviction (takes 149 ms)
• Windows: VirtualUnlock if possible (takes 17.69µs)
• Windows: SetProcessWorkingSetSize + eviction (takes
4.48 ms)
39 Daniel Gruss — Graz University of Technology
Countermeasures are Difficult www.tugraz.at
• We want the performance optimizations
• Many side-channel attacks exploit intended behavior
• Often a trade-off between security and performance
• Every optimization is potentially a side channel
42 Daniel Gruss — Graz University of Technology
Countermeasures are Difficult www.tugraz.at
• We want the performance optimizations
• Many side-channel attacks exploit intended behavior
• Often a trade-off between security and performance
• Every optimization is potentially a side channel
42 Daniel Gruss — Graz University of Technology
Countermeasures are Difficult www.tugraz.at
• We want the performance optimizations
• Many side-channel attacks exploit intended behavior
• Often a trade-off between security and performance
• Every optimization is potentially a side channel
42 Daniel Gruss — Graz University of Technology
Countermeasures are Difficult www.tugraz.at
• We want the performance optimizations
• Many side-channel attacks exploit intended behavior
• Often a trade-off between security and performance
• Every optimization is potentially a side channel
42 Daniel Gruss — Graz University of Technology
The Future www.tugraz.at
• We won’t get rid of side channels
• More optimizations → more side channels
• But: low hanging fruits will disappear
43 Daniel Gruss — Graz University of Technology
The Future www.tugraz.at
• We won’t get rid of side channels
• More optimizations → more side channels
• But: low hanging fruits will disappear
43 Daniel Gruss — Graz University of Technology
The Future www.tugraz.at
• We won’t get rid of side channels
• More optimizations → more side channels
• But: low hanging fruits will disappear
43 Daniel Gruss — Graz University of Technology
Software-based Microarchitectural Attacks
Daniel Gruss
July 8, 2018
Graz University of Technology
44 Daniel Gruss — Graz University of Technology
References
D. Gruss, C. Maurice, and S. Mangard. Rowhammer.js: A Remote
Software-Induced Fault Attack in JavaScript. In: DIMVA. 2016.
D. Gruss, R. Spreitzer, and S. Mangard. Cache Template Attacks: Automating
Attacks on Inclusive Last-Level Caches. In: USENIX Security Symposium. 2015.
M. Lipp, D. Gruss, R. Spreitzer, C. Maurice, and S. Mangard. ARMageddon:
Cache Attacks on Mobile Devices. In: USENIX Security Symposium. 2016.
Y. Oren, V. P. Kemerlis, S. Sethumadhavan, and A. D. Keromytis. The Spy in the
Sandbox: Practical Cache Attacks in JavaScript and their Implications. In: CCS.
2015.
M. Schwarz, D. Gruss, S. Weiser, C. Maurice, and S. Mangard. Malware Guard
Extension: Using SGX to Conceal Cache Attacks. In: DIMVA. 2017.