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 &timestamp , %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 &timestamp , %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.