The exploding popularity of Embedded/IoT computing facilitate this security problems using low or non-existent security policies and exploits countermeasures. So why not explore some security measures that are widely available in the Linux world? We will focus on memory corruption techniques.
The Linux kernel was always focused on security features and giving bad times to the exploiters. This talk will introduce some common exploits and techniques, showing the mitigations employed by the kernel. By focusing on the major threats that affects modern Linux boxes, we will see which are the main features that can give problems to the system administator and how a preliminary penetration test can be done, ensuring that the system is in a sane state. The talk will also focus on problematics of embedded/IoT Unix systems, showing how some recent attacks gained control over a big network of devices and how a simple embedded system can be analyzed, hunting for bugs. Talk outline: Penetration testing, Linux, netfilter/bpf, memory corruption, ASLR, Spectre/Meltdown.
Diamond Application Development Crafting Solutions with Precision
Davide Berardi - Linux hardening and security measures against Memory corruption
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.
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
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
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.
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();
}
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.
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