Integrity in Attestation and Isolation by Luca Wilke

 
The Role of Integrity in
Attestation and Isolation
 
L
u
c
a
 
W
i
l
k
e
Based on papers “SEVurity” and “undeSErved trust”
which are joint work with:
Jan Wichelmann, Florian Sieck, Mathias Morbitzer and Thomas Eisenbarth
 
 
1
 
Wilke,Wichelmann,Sieck,Eisenbarth, “undeSErVed trust: Exploiting Permutation-Agnostic Remote Attestation”, WOOT2021
Wilke,Wichelmann,Morbitzer,Eisenbarth, “SEVurity: No Security Without Integrity: Breaking Integrity-Free Memory Encryption with
Minimal Assumptions.", 2020 IEEE Symposium on Security and Privacy (SP)
Cloud Computing & Complex Software Stacks
2
Cloud Computing
requires trust in Hypervisor
shared resources between guests
⇒ TEEs can remove trust from Hypervisor
Complex Software Stacks
 
large attack surface
⇒ TEEs allow isolated “trust bubbles”
Attack
Attack
Attack
 
Trusted Execution Environments
 
3
TEE
Isolation at Runtime
Attestation of Content
Comercial TEEs
AMD SEV
4
ARM
Trustzone
Intel SGX
 
Attack
on SEV’s
Attestation
 
5
 
Attestation Protocol
 
6
Loading initial code image
7
Hash State = 丄
Hash State = A
Hash State = A,B
Measurement=HMAC(...,Finalize(Hash State);Key)
Loading initial code image
Hash State = ⊥
Hash State = A,B
Hash State = ⊥
Hash State = A,B
Run 1
Run 2
Different VM content, same measurement!
“Block” granularity is as low as 16 bytes
8
Measurement=HMAC(...,Finalize(Hash State);Key)
  Measurement=HMAC(...,Finalize(Hash State);Key)
 
Exploit
 
9
Example: Breaking a Password Check
10
...if( suppliedPw != correctPW ) { … abort(); … } ...
Original Code
Manipulated Code
Bootstrap Encryption/Decryption Oracles
 
1.
Reorder code blocks without changing
attestation
2.
Malicious Gadget maps VM’s stack to an
unencrypted page
3.
Hypervisor writes ROP addresses and
payload code onto VM’s stack
4.
ROP gadgets moves payload to private
page and executes it
11
“Blockchain” produced by
reordering the memory
blocks
Encryption/Decryption
Code Execution
 
Case Study : Stealing Disk Encryption Keys
 
12
 
Initialization
of VM
 
UEFI
 
Bootloader
 
OS
 
Protected by
Attestation
 
Loaded from
Encrypted Disk
 
Protected by
Attestation
 
Scenario
SEV only protects RAM; Disk Encryption is done in SW
Secure Processor has API to securely load secrets into
VM’s RAM
Attack
Use ROP gadget to move secret from encrypted memory
to unencrypted memory
 
Mitigations
 
SEV(-ES):
Increase minimal code block size in launch command
Include addresses of blocks in measurement
Neither can fully fix the problem due to untrusted Nested Page Tables
SEV(-SNP)
Nested Page Tables problem fixed
Attestation protocol has larger block sizes and includes addresses
 
13
 
CVE-2021-26311
 
Attack on SEV’s
Isolation
 
14
 
Encryption Mode
 
15
 
Old Mode
[DYM+]
 
Updated Mode
SEVurity
 
[DYM+]
 
Z.-H. Du, Z. Ying, Z. Ma, Y. Mai, P. Wang, J. Liu, and J. Fang, “Secure encrypted
virtualization is unsecure,” arXiv preprint arXiv:1712.05090, 2017
 
T
w
e
a
k
s
VM independent
Linear function of physical
address
 
Tweaks
 
16
 
Tweak(
0x1000
) = t
12
Tweak(
0x1010
) = t
12
 ⊕ t
4
 
Zen 1, Zen 1 Embedded
Low entropy, static  tweaks
Reverse engineered
Zen 2, (Zen 3?)
High entropy tweaks
Per boot randomness in tweaks
Tweaks unknown
 
Cipherblock Moving Attack
 
17
 
Cipherblock Moving Attack
 
 
18
 
Exploit
 
Using the guest kernel as a known plaintext source gives us control over
2 bytes
Upper limit is 4 bytes, due to tweak periodicity
Same exploit strategy as with attestation attack possible
Can use blocks more than once
Can alter memory layout on the fly
Moving ciphertext block changes its plaintext
 
19
 
Mitigations
 
Zen 2 CPUs have high entropy tweaks
SEV-SNP (Zen 3) prohibits Hypervisor from writing to VM memory
 
20
 
Conclusion
 
21
 
Summary
 
Reordering 16 byte code blocks allows construction of powerful malicious
gadgets
Two attack vectors
Attestation of SEV(-ES) does not detect permutations
Zen 1: XEX Cryptosystem with weak tweaks allows to move code blocks
Both attacks mitigated with SEV-SNP (Zen 3)
 
22
 
uzl-its.github.io/undeserved-trust/
uzl-its.github.io/SEVurity/
 
@lucawilkeUzL
@JanWichelmann
@tomcrypt
@Florian_UzL_ITS
 
Slide Archive
 
23
 
SEV Scenario
 
24
 
SEV Scenario
 
 
 
25
 
SEV Scenario
 
 
26
 
 
Bootstrap Encryption/Decryption Oracles
 
27
 
“Blockchain” produced by
reordering the memory
blocks
 
Read/Write Arbitrary Data
Execute Arbitrary Code
Case Study: Steal Disk Encryption Keys
 
Exploit
 
Same exploits as with attestation attack possible
Even more control, as we can
use blocks more than once
rewrite injected code on the fly
 
 
28
 
Case Study : Stealing Disk Encryption Keys
 
29
 
Initialization
of VM
 
UEFI
 
Bootloader
 
OS
 
Protected by
Attestation
 
Protected by
Disk Encryption
 
Protected by
Attestation
 
Scenario
SEV only protects RAM; Disk Encryption is done in SW
Secure Processor has API to securely load secrets into
VM’s RAM
Attack
Use ROP gadget to move secret from encrypted memory
to unencrypted memory
 
Creating SEV VMs : Boot Sequence
 
30
 
Initialization
of VM
 
UEFI
 
Bootloader
 
OS
 
vCPU jumps
to Reset
Vector
 
configures
CPU
 
 
Countermeasures
 
SEV(-ES)
Increase minimal size limit for measured blocks during launch
Makes exploitation harder
Limited to 4096 byte blocks (one page) due to page remapping flaw
Include addresses of blocks in measurement
Can ensure order inside a page but not beyond due to page remapping flaw
SEV(-SNP)
Page remapping flaw is resolved
Block size is increased to 
4096 bytes (page)
Addresses included in measurement
 
31
 
Responsible Disclosure
 
Disclosed to AMD on January 19th, 2021
Embargo until May 11, 2021
Mitigation with SEV-SNP on 3rd Gen EPYC
CVE-2021-26311
 
32
 
Exploiting Control Over Blocks v1
 
1.
Reorder initial VM image to create a
malicious code gadget
2.
Measure and start VM, Owner cannot
detect malicious gadget
Problems:
Does not scale well
Block availability might vary
 
33
 
“Blockchain” produced by
reordering the memory
blocks
 
Exploiting Control Over Blocks v2
 
1.
Reorder initial VM image to create a
malicious code gadget
2.
Measure and start VM, Owner cannot
detect malicious gadget
3.
Malicious Gadget maps some VM page as
unencrypted and jumps to it
4.
Hypervisor fills page with attack code
before jump
 Does not work: Code fetch always considers
page as encrypted
 
34
 
“Blockchain” produced by
reordering the memory
blocks
 
Case Study : Stealing Disk Encryption Keys
 
Scenario
SEV only protects RAM; Disk Encryption is done in SW
Secure Processor has API to securely load secrets in
VM RAM
Attack
Use ROP gadget to move secret from encrypted memory
to unencrypted memory
 
35
 
ROADMAP
 
-
Understand flaw in SEV (-ES) attestation
-
Exploit-Chain for Arbitrary Code execution
 
36
 
Creating SEV VMs : Launch Secrets
 
37
 
Derive two keys, 
TEK
 and 
TIK
, via DH
Key-Exchange.
 
HMAC is keyed with TIK -> Guest
Owner can verify
 
 
Guest Owner
encrypts+Integrity protects
Secret Data with TIK and TEK
 
Secure Processor stores
Secrets in VM RAM
Slide Note
Embed
Share

Explore the significance of integrity in the context of attestation and isolation in cloud computing and trusted execution environments. The research delves into the role of Trusted Execution Environments (TEE), commercial TEEs like ARM Trustzone, Intel SGX, and AMD SEV, potential attacks on SEV's attestation, and the importance of maintaining integrity in security protocols.


Uploaded on Jul 10, 2024 | 4 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. The Role of Integrity in Attestation and Isolation Luca Wilke Based on papers SEVurity and undeSErved trust which are joint work with: Jan Wichelmann, Florian Sieck, Mathias Morbitzer and Thomas Eisenbarth Wilke,Wichelmann,Sieck,Eisenbarth, undeSErVed trust: Exploiting Permutation-Agnostic Remote Attestation , WOOT2021 Wilke,Wichelmann,Morbitzer,Eisenbarth, SEVurity: No Security Without Integrity: Breaking Integrity-Free Memory Encryption with Minimal Assumptions.", 2020 IEEE Symposium on Security and Privacy (SP) 1

  2. Cloud Computing & Complex Software Stacks Cloud Computing requires trust in Hypervisor shared resources between guests TEEs can remove trust from Hypervisor Attack Complex Software Stacks large attack surface TEEs allow isolated trust bubbles Attack Attack 2

  3. Trusted Execution Environments TEE Attestation of Content Isolation at Runtime 3

  4. Comercial TEEs ARM Trustzone Intel SGX AMD SEV 4

  5. Attack on SEV s Attestation 5

  6. Attestation Protocol 6

  7. Loading initial code image Hash State = Hash State = A Hash State = A,B Measurement=HMAC(...,Finalize(Hash State);Key) 7

  8. Loading initial code image Run 1 Run 2 Hash State = A,B Hash State = A,B Hash State = Hash State = Measurement=HMAC(...,Finalize(Hash State);Key) Measurement=HMAC(...,Finalize(Hash State);Key) Different VM content, same measurement! Block granularity is as low as 16 bytes 8

  9. Exploit 9

  10. Example: Breaking a Password Check ...if( suppliedPw != correctPW ) { abort(); } ... Original Code Manipulated Code 10

  11. Bootstrap Encryption/Decryption Oracles 1. Reorder code blocks without changing attestation 2. Malicious Gadget maps VM s stack to an unencrypted page 3. Hypervisor writes ROP addresses and payload code onto VM s stack 4. ROP gadgets moves payload to private page and executes it Blockchain produced by reordering the memory blocks Encryption/Decryption Code Execution 11

  12. Case Study : Stealing Disk Encryption Keys Initialization of VM Scenario SEV only protects RAM; Disk Encryption is done in SW Secure Processor has API to securely load secrets into VM s RAM Protected by Attestation UEFI Attack Protected by Attestation Bootloader Use ROP gadget to move secret from encrypted memory to unencrypted memory Loaded from Encrypted Disk OS 12

  13. Mitigations SEV(-ES): SEV(-SNP) Increase minimal code block size in launch command Include addresses of blocks in measurement Neither can fully fix the problem due to untrusted Nested Page Tables Nested Page Tables problem fixed Attestation protocol has larger block sizes and includes addresses 13

  14. Attack on SEVs Isolation 14

  15. Encryption Mode Old Mode [DYM+] Updated Mode SEVurity Tweaks VM independent Linear function of physical address 15 [DYM+] Z.-H. Du, Z. Ying, Z. Ma, Y. Mai, P. Wang, J. Liu, and J. Fang, Secure encrypted virtualization is unsecure, arXiv preprint arXiv:1712.05090, 2017

  16. Tweaks Tweak constant Zen 1, Zen 1 Embedded Low entropy, static tweaks Reverse engineered Zen 2, (Zen 3?) High entropy tweaks Per boot randomness in tweaks Tweaks unknown Value (16 Byte) t2 82 25 38 38 .... t5 ec 09 9c ec ... ... ... t12 b0 92 30 c2 ... ... ... Tweak(0x1000) = t12 Tweak(0x1010) = t12 t4 16

  17. Cipherblock Moving Attack 17

  18. Cipherblock Moving Attack 18

  19. Exploit Using the guest kernel as a known plaintext source gives us control over 2 bytes Upper limit is 4 bytes, due to tweak periodicity Same exploit strategy as with attestation attack possible Can use blocks more than once Can alter memory layout on the fly Moving ciphertext block changes its plaintext 19

  20. Mitigations Zen 2 CPUs have high entropy tweaks SEV-SNP (Zen 3) prohibits Hypervisor from writing to VM memory 20

  21. Conclusion 21

  22. Summary Reordering 16 byte code blocks allows construction of powerful malicious gadgets Two attack vectors Attestation of SEV(-ES) does not detect permutations Zen 1: XEX Cryptosystem with weak tweaks allows to move code blocks Both attacks mitigated with SEV-SNP (Zen 3) @lucawilkeUzL @JanWichelmann @tomcrypt @Florian_UzL_ITS uzl-its.github.io/undeserved-trust/ uzl-its.github.io/SEVurity/ 22

  23. Slide Archive 23

  24. SEV Scenario 24

  25. SEV Scenario 25

  26. SEV Scenario 26

  27. Bootstrap Encryption/Decryption Oracles Read/Write Arbitrary Data Execute Arbitrary Code Case Study: Steal Disk Encryption Keys Blockchain produced by reordering the memory blocks 27

  28. Exploit Same exploits as with attestation attack possible Even more control, as we can use blocks more than once rewrite injected code on the fly 28

  29. Case Study : Stealing Disk Encryption Keys Initialization of VM Scenario SEV only protects RAM; Disk Encryption is done in SW Secure Processor has API to securely load secrets into VM s RAM Protected by Attestation UEFI Attack Protected by Attestation Bootloader Use ROP gadget to move secret from encrypted memory to unencrypted memory Protected by Disk Encryption OS 29

  30. Creating SEV VMs : Boot Sequence vCPU jumps to Reset Vector configures CPU Initialization of VM UEFI Bootloader OS 30

  31. Countermeasures SEV(-ES) Increase minimal size limit for measured blocks during launch Makes exploitation harder Limited to 4096 byte blocks (one page) due to page remapping flaw Include addresses of blocks in measurement Can ensure order inside a page but not beyond due to page remapping flaw SEV(-SNP) Page remapping flaw is resolved Block size is increased to 4096 bytes (page) Addresses included in measurement 31

  32. Responsible Disclosure Disclosed to AMD on January 19th, 2021 Embargo until May 11, 2021 Mitigation with SEV-SNP on 3rd Gen EPYC CVE-2021-26311 32

  33. Exploiting Control Over Blocks v1 1. Reorder initial VM image to create a malicious code gadget 2. Measure and start VM, Owner cannot detect malicious gadget Problems: Does not scale well Block availability might vary Blockchain produced by reordering the memory blocks 33

  34. Exploiting Control Over Blocks v2 1. Reorder initial VM image to create a malicious code gadget 2. Measure and start VM, Owner cannot detect malicious gadget 3. Malicious Gadget maps some VM page as unencrypted and jumps to it 4. Hypervisor fills page with attack code before jump Does not work: Code fetch always considers page as encrypted Blockchain produced by reordering the memory blocks 34

  35. Case Study : Stealing Disk Encryption Keys Scenario SEV only protects RAM; Disk Encryption is done in SW Secure Processor has API to securely load secrets in VM RAM Attack Use ROP gadget to move secret from encrypted memory to unencrypted memory 35

  36. ROADMAP - - Understand flaw in SEV (-ES) attestation Exploit-Chain for Arbitrary Code execution 36

  37. Creating SEV VMs : Launch Secrets Derive two keys, TEK and TIK, via DH Key-Exchange. HMAC is keyed with TIK -> Guest Owner can verify Guest Owner encrypts+Integrity protects Secret Data with TIK and TEK Secure Processor stores Secrets in VM RAM 37

More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#