attacking a co hosted vm
play

Attacking a co-hosted VM A hacker, a hammer and two memory modules - PowerPoint PPT Presentation

Attacking a co-hosted VM A hacker, a hammer and two memory modules 1 Who we are (1) Mehdi Talbi Security researcher at Stormshield haka-security project. Past life: academia (phd, postdoc, ) Main research topics: advanced


  1. Attacking a co-hosted VM A hacker, a hammer and two memory modules 1

  2. Who we are (1) Mehdi Talbi • Security researcher at Stormshield • haka-security project. • Past life: academia (phd, postdoc, …) • Main research topics: advanced exploitation techniques, abusing virtual machines (phrack paper), low-level stuff, … @abu_y0ussef mtalbi.github.io 2

  3. Who we are (2) Paul Fariello • Security engineer at Stormshield • haka-security project. • Past life: Software developer at Stormshield • Main interest: low-level stuff, vulnerability exploitation, software engineering 3

  4. The attack Goal: authenticate on the victim VM - given that: • Credentials are not known to the attacker • Victim VM is not vulnerable to any software bug 4

  5. Teaser 5

  6. Teaser 5

  7. Agenda • Row-hammering (from a VM) • Abusing memory de-duplication • Pwning the libpam • Conclusion 6

  8. Row-hammering 7

  9. The Bug • DRAM Chip: rows of cells (refreshed periodically) • Read/Write operation Data is transferred to the row-buffer • ( discharging ) Data is copied back to the original row • ( recharging ) • Frequent row activation (discharging + recharging) -> Disturbance errors -> high discharge rate on adjacent row’s cells -> bit-flips in adjacent memory rows (if they are not refreshed before they lose their charge) 8

  10. The Code 1 code1a: 2 mov (X), %eax /* read from address X */ 3 mov (Y), %ebx /* read from address Y */ 4 clflush (X) /* flush cache for address X */ 5 clflush (Y) /* flush cache for address Y */ 6 jmp code1a 9

  11. Past attacks - Timeline 10

  12. Past attacks - Timeline June 2014 - Yoongu Kim et al. Flipping bits in memory without accessing them 10

  13. Past attacks - Timeline June 2014 - Yoongu Kim et al. Flipping bits in memory without accessing them March 2015 - Mark Seaborn and Thomas Dullien Exploiting the DRAM rowhammer bug to gain kernel privileges 10

  14. Past attacks - Timeline May 2016 - Erik Bosman et al. Dedup Est Machina June 2014 - Yoongu Kim et al. Flipping bits in memory without accessing them March 2015 - Mark Seaborn and Thomas Dullien Exploiting the DRAM rowhammer bug to gain kernel privileges 10

  15. Past attacks - Timeline May 2016 - Erik Bosman et al. Dedup Est Machina June 2014 - Yoongu Kim et al. Flipping bits in memory without accessing them March 2015 - Mark Seaborn and Thomas Dullien August 2016 - Kaveh Razavi et al. Exploiting the DRAM rowhammer bug to gain Flip Feng Shui kernel privileges 10

  16. Past attacks - Timeline May 2016 - Erik Bosman et al. October 2016 - Victor Van Der Venn et al. Dedup Est Machina Drammer June 2014 - Yoongu Kim et al. Flipping bits in memory without accessing them March 2015 - Mark Seaborn and Thomas Dullien August 2016 - Kaveh Razavi et al. Exploiting the DRAM rowhammer bug to gain Flip Feng Shui kernel privileges 10

  17. Channels, ranks, banks • channel : multiple memory modules • memory module: multiple memory chips may be available on both sides ( ranks ) • memory chips made of banks • bank: matrix ( column X rows ) of memory cells. 11

  18. DRAM Config. • 8 GB of RAM • 2 channels • 1 memory module / channel • 2 ranks / memory module • 8 memory chips / rank • 8 bank / chip • 2^15 rows x 2^10 columns x 8 bits / bank Total Size = 2 modules * 2 ranks * 2^3 chips * 2^3 banks * 2^15 rows * 2^10 columns * 1 byte = 8 GB 12

  19. Memory Geometry • How physical addresses map to channels, ranks, banks ? 13

  20. Memory Geometry • How physical addresses map to channels, ranks, banks ? • Mark Seaborn has determined the address mapping for Sandy Bridge microarchitecture: Bits 0-5: lower 6 bits of byte index within a row • Bit 6: channel selection • Bits 7-13: higher 7 bits of byte index within a row • Bits 14-16: bank selection obtained by: • ((addr >> 14) & 7) ^ ((addr >> 18) & 7) Bit 17: rank selection • Bit 18-32: row selection • 13

  21. Row-hammering from a VM 14

  22. Row-hammering from a VM • How to pick a couple of addresses (a_1, a_2) to hammer such that: a_1 is in row r, • a_2 is in row r+2, • a_1 and a_2 are in the same bank b ? • 14

  23. Row-hammering from a VM • How to pick a couple of addresses (a_1, a_2) to hammer such that: a_1 is in row r, • a_2 is in row r+2, • a_1 and a_2 are in the same bank b ? • • We don’t have access to host’s pagemap file :-( 14

  24. Row-hammering from a VM • How to pick a couple of addresses (a_1, a_2) to hammer such that: a_1 is in row r, • a_2 is in row r+2, • a_1 and a_2 are in the same bank b ? • • We don’t have access to host’s pagemap file :-( • Option: Transparent Huge Pages 14

  25. Transparent Huge Pages • khugepaged is a kernel thread that attempts to allocate huge pages of 2 MB size. • A huge page covers multiple rows: row size = 2 × 2 20 page size = 8 rows 2 18 • We can navigate through rows !! 15

  26. Transparent Huge Pages 16

  27. Transparent Huge Pages We allocate in the guest a • large buffer (available physical RAM) aligned on 2 MB boundary. 16

  28. Transparent Huge Pages We allocate in the guest a • large buffer (available physical RAM) aligned on 2 MB boundary. khugepaged running in the • guest will try to back the buffer by huge pages. 16

  29. Transparent Huge Pages We allocate in the guest a • large buffer (available physical RAM) aligned on 2 MB boundary. khugepaged running in the • guest will try to back the buffer by huge pages. The same goes for • khugepaged running in the host. 16

  30. Row Selection 17

  31. Row Selection • Hammer each pair of rows i, i+2 (double-sided row-hammer). 17

  32. Row Selection • Hammer each pair of rows i, i+2 (double-sided row-hammer). • We can select pair of addresses from (i, i+2) that belong to the same rank, channel. How about banks? 17

  33. Row Selection • Hammer each pair of rows i, i+2 (double-sided row-hammer). • We can select pair of addresses from (i, i+2) that belong to the same rank, channel. How about banks? • Let and bits identifying a bank in row i and j, respectively. b i 1 b i 2 b i 3 b j 1 b j 2 b j 3 • We hammer each address from row i with the address from j (j = i + 2) satisfying this condition: b i 3 = b j 3 b i 1 b i 2 6 = b j 1 b j 2 17

  34. Quad-Hammering 1 static void hammer_byte(uintptr_t aggressors[]) 2 { 3 volatile uint64_t *a = (volatile uint64_t *)aggressors[0]; 4 volatile uint64_t *b = (volatile uint64_t *)aggressors[1]; 5 volatile uint64_t *c = (volatile uint64_t *)aggressors[2]; 6 volatile uint64_t *d = (volatile uint64_t *)aggressors[3]; 7 8 int nb_reads = READ_REPZ; 9 10 while (nb_reads-- > 0) { 11 *a; 12 *b; 13 *c; 14 *d; 15 asm volatile ( 16 "clflush (%0)\n\t" 17 "clflush (%1)\n\t" 18 "clflush (%2)\n\t" 19 "clflush (%3)\n\t" 20 : 21 : "r" (a), "r" (b), "r" (c), "r" (d) 22 : "memory" 23 ); 24 } 25 } 18

  35. Abusing memory de-duplication 19

  36. Memory De-duplication Before Merging After Merging 20

  37. Attack Steps 21

  38. Attack Steps Goal: Modify a bit in a file (e.g. pam_unix.so) hosted in the victim VM assuming we know its content. 21

  39. Attack Steps Goal: Modify a bit in a file (e.g. pam_unix.so) hosted in the victim VM assuming we know its content. Hint: Row-hammering is reproducible 21

  40. Attack Steps Goal: Modify a bit in a file (e.g. pam_unix.so) hosted in the victim VM assuming we know its content. Hint: Row-hammering is reproducible 1. Map the available physical memory 21

  41. Attack Steps Goal: Modify a bit in a file (e.g. pam_unix.so) hosted in the victim VM assuming we know its content. Hint: Row-hammering is reproducible 1. Map the available physical memory 2. Hammer the memory from attacker VM 21

  42. Attack Steps Goal: Modify a bit in a file (e.g. pam_unix.so) hosted in the victim VM assuming we know its content. Hint: Row-hammering is reproducible 1. Map the available physical memory 2. Hammer the memory from attacker VM 3. Load the target file in the victim VM (e.g. by trying to authenticate on the victim VM) 21

  43. Attack Steps Goal: Modify a bit in a file (e.g. pam_unix.so) hosted in the victim VM assuming we know its content. Hint: Row-hammering is reproducible 1. Map the available physical memory 2. Hammer the memory from attacker VM 3. Load the target file in the victim VM (e.g. by trying to authenticate on the victim VM) 4. Wait for memory deduplication. 21

  44. Attack Steps Goal: Modify a bit in a file (e.g. pam_unix.so) hosted in the victim VM assuming we know its content. Hint: Row-hammering is reproducible 1. Map the available physical memory 2. Hammer the memory from attacker VM 3. Load the target file in the victim VM (e.g. by trying to authenticate on the victim VM) 4. Wait for memory deduplication. 5. Hammer again 21

Recommend


More recommend