The document discusses Linux hardening techniques and mitigations against memory corruption vulnerabilities, highlighting specific CVEs related to memory safety bugs that could be exploited. It covers various mitigation strategies such as Non-Executable Stack, Address Space Layout Randomization (ASLR), and Stack Canaries, and introduces advanced concepts like Return-Oriented Programming (ROP) and Side Channels (Spectre). The presentation concludes with discussions on modern mitigation techniques and the importance of kernel self-protection projects.

1. Linux hardening and mitigations
against memory corruption
Davide Berardi
3 december 2018

2. Who am I?
Davide Berardi
▶ davide.berardi6@unibo.it
▶ PhD @ University of Bologna since
november 2018.
▶ Firmware Engineer @ T3Lab since
december 2016.

3. Memory Corruption
Why I’m talking about this old vulnerability class
CVE-2018-5188 Memory safety bugs present in Firefox 60 [...]
Some of these bugs showed evidence of memory
corruption and we presume that with enough effort
that some of these could be exploited to run arbitrary
code. [...]
CVE-2018-6069 Stack buffer overflow in Skia in Google Chrome
prior to 65.0.3325.146 allowed a remote attacker to
perform an out of bounds memory read via a crafted
HTML page.
CVE-2018-16842 Curl versions 7.14.1 through 7.61.1 are vulnerable
to a heap-based buffer over-read in the
tool_msgs.c:voutf() function that may result in
information exposure and denial of service.

4. Spooky stories!

5. Buffer Overflow
Introduction
C Code
uint32_t a;
unsigned char b[4];
ASM
sub esp,0x8
a
b

6. Buffer Overflow
Introduction
C Code
int foo(int _) { }
foo(a);
ASM
call foo
Local parameters
Return address
Saved state
Local variables

7. Buffer Overflow
Introduction
C Code
int foo(int _) {
uint32_t a;
char b[4];
return 0;
}
Local parameters
Return address
Saved State
a
b

8. Buffer Overflow
Introduction
C Code
int foo(int _) {
uint32_t a;
char b[4];
==> gets(b);
return 0;
}
Local parameters
Return address
Saved State
a
b

9. Buffer Overflow
Introduction
C Code
int foo(int _) {
uint32_t a;
char b[4];
==> gets(b);
return 0;
}
Local parameters
Return address
Saved State
a
A A A A

10. Buffer Overflow
Introduction
C Code
int foo(int _) {
uint32_t a;
char b[4];
==> gets(b);
return 0;
}
Local parameters
Return address
Saved State
aA A A A
A A A A

11. Buffer Overflow
Introduction
C Code
int foo(int _) {
uint32_t a;
char b[4];
==> gets(b);
return 0;
}
Local parameters
Return address
A A A A
A A A A
A A A A

12. Buffer Overflow
Introduction
C Code
int foo(int _) {
uint32_t a;
char b[4];
==> gets(b);
return 0;
}
Local parameters
A A A A
A A A A
A A A A
A A A A

13. Buffer Overflow
Introduction
C Code
int foo(int _) {
uint32_t a;
char b[4];
gets(b);
==> return 0;
}
Local parameters
A A A A
A A A A
A A A A
A A A A

14. Buffer Overflow
Introduction

15. Buffer Overflow
Shellcode
▶ Inject code in the application.
xor %eax,%eax
push %eax
push $0x68732f2f
push $0x6e69622f
mov %esp,%ebx
push %eax
push %ebx
mov %esp,%ecx
mov $0xb,%al
int $0x80
syscall(11, "/bin/sh");
or, in equal words
exec("/bin/sh");

16. Buffer Overflow
Shellcode
C Code
int foo(int _) {
uint32_t a;
char b[4];
gets(b);
==> return 0;
}
Local parameters
0x......
Shellcode

17. Buffer Overflow
Shellcode

18. Mitigation
Non executable stack
▶ What if the stack was not executable?
▶ PaX patch suite.
~ % checksec --output csv -f $(which ping) |
awk -F , '{print␣$3}'
NX enabled

19. Buffer Overflow
Introduction

20. Buffer Overflow
Return 2 libc
C Code
int foo(int _) {
uint32_t a;
char b[4];
gets(b);
==> return 0;
}
Local parameters
Address of system
Padding

21. Buffer Overflow
Return 2 libc
C Code
int foo(int _) {
uint32_t a;
char b[4];
gets(b);
==> return 0;
}
Previous AR
Fake return
Address of system
Padding

22. Buffer Overflow
Return 2 libc
C Code
int foo(int _) {
uint32_t a;
char b[4];
gets(b);
==> return 0;
}
Address of ”/bin/sh”
Fake return
Address of system
Padding

23. Buffer Overflow
Return Oriented Programming
▶ What the attacker can do if the programs doesn’t
have any useful target function?
▶ e.g. no libc or no useful (for the exploitation)
functions at all.
▶ Weird machines!
Weird
MachineInput Output
Malicious Input Exploit

24. Buffer Overflow
ROP¹
ASM gadget1:
mov eax, 11; ret
ASM gadget2:
mov ebx,&"/bin/sh"; ret
ASM gadget3:
mov ecx,&&"/bin/sh"; ret
ASM gadget4:
mov edx,0; ret
ASM gadget5:
int 0x80; ret
Fake Return
Address of gadget5
Address of gadget4
Address of gadget3
Address of gadget2
Address of gadget1
Padding
¹simplified

25. Mitigation
ASLR
▶ Attackers need the address of functions and
gadgets.
▶ Address Source Layout Randomization.
▶ cat /proc/sys/vm/mmap_rnd_bits
$ ldd $(which whoami) | awk '/libc/{print␣$NF}'
(0x00007f6586ee8000)
$ ldd $(which whoami) | awk '/libc/{print␣$NF}'
(0x00007f7bba165000)

26. Information Leak
printf format parameter leak
C Code:
#include <stdio.h>
#include <stdint.h>
int main(int argc, char **argv) {
uintptr_t token = 0x1234;
return printf(argv[1]);
}
Exploit:
$ ./foo hello
hello
$ ./foo %p
0x7ffedf09fb10
$ ./foo %9$p
0x1234

27. Information Leak
Fork ASLR
▶ Fork won’t change process mappings.
#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
int main()
{
if (fork()) {
printf("C:␣%pn",
printf);
return 0;
}
printf("P:␣%pn",
printf);
wait(NULL);
return 0;
}
$ /tmp/test
C: 0x7f99c155b3a0
P: 0x7f99c155b3a0
$ /tmp/test
C: 0x7f8bc12253a0
P: 0x7f8bc12253a0

28. Side channels
Spectre CVE-2017-5753
▶ Spectre is a CPU bug tied to the BPU and the Cache.
▶ On a wrong guess of the BPU the cache isn’t
invalidated.
▶ This can lead us to Information Leak.

29. Side channels
Spectre CVE-2017-5753
Cache
...
if (a < b)
array2[array1[a]] ”warning”
return

30. Side channels
Spectre CVE-2017-5753
Cache
array2[array1[a]]
if (a < b)
array2[array1[a]] ”warning”
return

31. Side channels
Spectre CVE-2017-5753
Cache
array2[array1[a]]
if (a < b)
array2[array1[a]] ”warning”
return

32. Side channels
Spectre CVE-2017-5753
Cache
...
if (a < b)
array2[array1[a]] ”warning”
return

33. Side channels
Spectre CVE-2017-5753
Cache
...
if (a < b)
array2[array1[a]] ”warning”
return

34. Side channels
Spectre CVE-2017-5753
Cache
array2[array1[a]]
if (a < b)
array2[array1[a]] ”warning”
return

35. Side channels
Spectre CVE-2017-5753
Cache
array2[array1[a]]
▶ Now we can leak the memory!
▶ array1[a] == 2
array2[0]
∆time ∼= x
array2[1]
∆time ∼= x
array2[2]
∆time ≪ x

36. Mitigation
Stack canaries
gcc -fstack-protector{,-all,-strong,-explicit}
mov %fs:0x28,%rax
mov %rax,-0x8(%rbp)
...
mov -0x8(%rbp),%rcx
xor %fs:0x28,%rcx
je foo+131
callq stack_chk_fail
...
Local parameters
Return address
Stack Canary
Saved State
a
b

37. Mitigation
Stack canaries
▶ Terminator Canary
0x000d0aff
▶ Random Canary
0xXXXXXXXX
▶ Xor Canary
0xXXXXXXXX ⊕ Data
▶ Pointer Encryption
QARMAE(Ret.Addr)

38. Memory Corruptions
-fsanitize
Vulnerable program:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
void *s[64] = {};
printf("%pn",
s[63 - atoi(argv[1]));
return 0;
}
$ clang test.c
$ ./a.out 1
(nil)
$ ./a.out 2
(nil)
$ ./a.out -1
0x7ffe3187bf10

39. Memory Corruptions
-fsanitize

40. Fuzzer
AFL
▶ American Fuzzy Lop.

41. Advanced attacks
▶ Heap Overflow;
▶ Integer overflow;
▶ Race conditions (TOCTTOU, Dirty cow, ...);
▶ Type confusion;
▶ Data only attacks;
▶ Side channels (Spectre, Meltdown, RowHammer, ...);
▶ sROP.

42. Advanced mitigations
▶ RelRO.
▶ PIE.
▶ Memory Tagging.
▶ Pointer Authentication.
▶ OpenBSD-style malloc.
▶ BPF_HARDEN.
▶ Shadow stacks.
▶ Alloca Checks.
▶ Guard Pages.
▶ PAX and GRSEC patches (PAX_REFCOUNT,
PAX_SIZE_OVERFLOW, PAX_USERCOPY,
PAX_MEMORY_STACKLEAK, PAX_MEMORY_STRUCTLEAK,
PAX_MEMORY_SANITIZE, GRSEC_HIDESYM,
PAX_CONSTIFY_PLUGIN, PAX_MEMORY_UNDERREF, ...).
▶ CFI / GRSEC RAP.

43. Thank you for your
attention.

44. Mitigration
Shadow stacks
▶ A shadow stack is a stack which is not editable by
the attacker.
▶ Upon a return from a procedure the application will
compare the call-stack values and its shadow
values, if they differs an exception is raised.
Shadow
Stack Exec ReturnInput Output
compare

45. Mitigation
Guard Pages
▶ A guard page memory page is placed between the
stack and the heap.
Stack
Heap
Stack
Heap
Guard

46. Other problems
Alloca and VLA
▶ alloca will allocate memory on the stack, this
facilitates stack smashing and stack overflow!
▶ There are alloca checkers, so you can trace and
hunt bugs based on this feature.
int *x = alloca(3 * sizeof(int));
▶ VLA (variable length arrays), allocated using alloca.
▶ Security Nightmare (and bad practice)!
int foo(int a)
{
int x[a];
}

47. Mitigation
RelRO
▶ A position indipendent executable can be placed in
every part of the memory.
▶ The linker need to use two tables to load the
dependencies: GOT and PLT;
<main>
callq 1030 <printf@plt >
...
<printf@plt >:
jmpq *0x2fe2(%rip) # printf@GLIBC_2.2.5
pushq $0x0
jmpq 1020 <.plt>
▶ These tables are still writable and can hijack
functions!
▶ RelRO places this tables in read only memory, so
you need to known only an offset at loading time.

48. Buffer Overflow
SROP
▶ Using rop we can allocate on the stack a gadget
which contains sigreturn systemcall.
▶ Before that we can place a sigcontext_t fake
structure.
▶ The program will return to the allocated context,
effectively running our shellcode.
gadgetsigreturn
sigcontext_t
▶ Mitigations are similar to the one described for stack
smashing: Signal cookies (stack canaries), ASLR, ...
▶ Disabled vsyscall support.

49. Mitigations
Intel MPX
▶ From Intel generation 6 (Sky lake).
▶ Registers and instructions to check if pointer
bounds are valid.
BNDCU BND2

50. Buffer Overflow
Heap Overflow
▶ We can hijack malloc control fields
(malloc-maleficarium, House of Einherjar).
#include <cstdio >
#include <cstring >
class O {
private:
char buf[256];
public:
void getusr(char *b) {
strcpy(buf, b);
}
virtual void print() {
printf("%sn", buf);
}
};
int main(int argc,
char **argv)
{
O *o[2]={new O(),
new O()};
o[0]->getusr(argv[1]);
o[1]->getusr(argv[2]);
o[0]->print();
o[1]->print();
}

51. Buffer Overflow
Heap overflow
o[0]->buf
o[0]->vtable
o[1]->vtable
o[1]->buf
o[0]->vtable
AAAA
AAAA
BBBB

52. Side channels
Row hammer
▶ Data handling in DRAM is supscetible to massaging.
▶ Resolved in LPDDR4.
▶ Can bypass ECC!
Write Manipulated

53. Control Flow Integrity
clang −fsanitize= c f i −f v i s i b i l i t y =hidden −f l t o
▶ You can view your program as a graph.
▶ Forward-edge-control-flow-integrity
▶ Backward-edge-contol-flow-integrity
typedef void *(*foo_t)(void *);
void *foo(void *_) { ... }
void *bar(void *_) { ... }
foo_t foos[2];
int main(int argc, char **argv) {
return foo[atoi(argv[1][0])](NULL);
}

54. Side channels
MeltDown
▶ For performance memory mapping is not changed
upon a context switch (but is protected using a
guard value).
raise_exception();
// the line below is never reached
access(probe_array[data * 4096]);
▶ With KAISER the kernel get swapped out from the
user space.

55. Side channels
SpectreV2
▶ Indirect branch predictions.
C:
class Base {
public:
virtual void Foo() = 0;
};
class Derived : public Base {
public:
void Foo() override { … }
};
Base* obj = new Derived;
obj->Foo();
ASM:
...
jmp [r15]
...

56. Side channels
Spectre Mitigations
▶ LFENCE - serialization instruction;
▶ Retpoline - hack to avoid processor speculation on
indirect branch prediction.
jmp [r15]
Retpoline will rewrite this
indirect call to:
call set_up_target
loop:
pause
jmp loop
set_up_target:
mov r15, [rsp]
ret
lfence
; All instructions
; are serialized.

57. Fuzzer
Syzkallerz

58. Kernel Self Protection Project
▶ Not protecting user space
applications.
▶ Not protecting versus specific
attacks.
▶ But protecting the kernel itself
from attack classes.
▶ https:
//kernsec.org/wiki/index.php/
Kernel_Self_Protection_Project