Protection and Mitigation of Software Bug Exploitation

Vartan Padaryan vartan@ispras.ru

1

How safe is latest Linux release?

• Command line arguments fuzzer (inspired by Brumley’s article) – Launch programs with two parameters:

• -a..-z, -A..-Z • A long string (~6000 characters)

– Quite good results • Arch Linux, Debian, … • 3300 applications checked • Found 211 crashes in 47 applications

• However, it is unlikely that crash can be escalated to something more dangerous …

– Targeted data corruption – Sensitive data leaks – Arbitrary code injection

• How can one precisely evaluate the impact of found defect? – Construct exploit for the bug

2

Factors contributing towards software security

• Hardware properties – Von Neumann architecture – source of security issues – Harvard architecture, DEP

• Development tools – C/C++ languages, address arithmetic – Compiler/libraries – Security analyzers

• Organizational measures – Cisco Secure Development Lifecycle – Microsoft the Security Development Lifecycle – … – Any large enough software company has its own

methodology and practice of secure development

3

(Slice of) Microsoft SDL

Implementation

• #8 Use Approved Tools

• #9 Deprecate Unsafe Functions

• #10 Perform Static Analysis

Verification

• #11 Perform Dynamic Analysis

• #12 Perform Fuzz Testing

• #13 Conduct Attack Surface Review

Release

• #14 Create an Incident Response Plan

• #15 Conduct Final Security Review

• #16 Certify Release and Archive

Response

• Execute Incident Response Plan

4

Developer tools

Compiler

Secure libraries

Traditional debuggers and

profilers

DBI-based automated debugging

Static analysis during nightly builds

Static analysis built in IDE

5

Canary …

• Canary word is placed between a buffer and control data on the stack to monitor buffer overflows

• Corruption of canary indicates that return address also may be changed

• Default option for gcc since 2012

6

Function prologue: copy canary from TLS into current frame

Return address

Canary word

buf

...

0

Stack frame

Function body

Function epilogue: compare TLS and frame canaries, if not equal, abort function without RET execution

… and other compiler techniques (1/3)

• Available out-of-the-box (gcc)

– FORTIFY_SOURCE secure version of some standard functions strcpy __strcpy_chk

– Compile time check for various danger patterns

• User defined format string

– Safe memory layout for automatic variables

7

int someFunc() { int *p1; char buf[12]; int *p2; ...

Return address

Canary word

buf

p1

p2

Stack frame

0

… and other compiler techniques (2/3)

• Available out-of-the-box (gcc)

– FORTIFY_SOURCE secure version of some standard functions strcpy __strcpy_chk

– Compile time check for various danger patterns

• User defined format string

– Safe memory layout for automatic variables

8

struct some_struct { int *p1; char buf[12]; int *p2; ...

buf p1 p2

Memory layout

0

… and other compiler techniques (3/3)

• Other techniques – Shadow stack

– Secure heap for sensitive automatic variables

– Control flow integrity

– …

• Aggressive optimization can introduce bug where it didn’t exist before

• Result: – WYSINWYX: What You See Is Not What You eXecute

9

@article{Balakrishnan:2010:WYS:1749608.1749612, author = {Balakrishnan, Gogul and Reps, Thomas}, title = {WYSINWYX: What You See is Not What You eXecute}, journal = {ACM Trans. Program. Lang. Syst.}, issue_date = {August 2010}, }

memset(password, ‘\0’, len); free(password);

Tools for testers / release manager / …

10

CI, Unit testing

…

Fuzzing

Security check for AppStore

(Taint analysis)

Symbolic execution (?)

Symbolic execution (1/2)

• Old good technique to improve code coverage • Applicable at source and binary level • Native drawback – path explosion

11

input(x); char buf[42];

if x>0

if x*x < 0xffffff

strcpy(buf, input)

t f

t f

x – free symbolic variable

(x > 0)

(x > 0) ¬(x*x < 0xffffff)

Symbolic execution (2/2)

• SMT-solver tries to evaluate system of path and security predicates – Security predicate describes certain exploit

• Available well constructed frameworks – KLEE (LLVM)

– S2E (binary, whole system analysis, QEMU-based)

• Numerous publications – EXE, BitBlaze (Berkeley), Mayhem (CMU), Sage (Microsoft),

Driller (UC), Dowser, …

– There are no publications on how to construct an exploit in case of activated compile-time protection (activated by default)

12

Why the only tool is not enough

1 char buf[32]; 2 char *data = read_string(); 3 unsigned int magic = read_number(); 4 5 // difficult check for fuzzing 6 if (magic == 0x31337987) { 7 // buffer overflow 8 memcpy(buf, data, 100); 9 } 10 11 if (magic < 100 && magic % 15 == 2 && magic % 11 == 6) { 12 // Only solution is 17; safe 13 memcpy(buf, data, magic); 14 } 15 16 // Symbolic execution will suffer from path explosion 17 int count = 0; 18 for (int i = 0; i < 100; i++) { 19 if (data[i] == ’Z’) { 20 count++; 21 } 22 } 23 24 if (count >= 8 && count <= 16) { 25 // buffer overflow 26 memcpy(buf, data, count*20); 27 }

13

@article{shoshitaishvili2016state, title={SoK: (State of) The Art of War: Offensive Techniques in Binary Analysis}, author={Shoshitaishvili, Yan and Wang, Ruoyu and Salls, Christopher and Stephens, Nick and Polino, Mario and Dutcher, Andrew and Grosen, John and Feng, Siji and Hauser, Christophe and Kruegel, Christopher and Vigna, Giovanni}, booktitle={IEEE Symposium on Security and Privacy}, year={2016} }

Explore malicious code in third party software

• AppStore needs to check application for malicious behavior before distributing

– Leak sensitive data

– Spam broadcast

– Backdoor for further code injection

• TEMU, TaintDroid, DroidScope, …

– Various implementations of tainted input analysis

14

Taint analysis

15

Taint source #1

Taint source #2

Merge of different sources

Program variables

Method / implementations restrictions

• Control dependencies

• Data flow goes across a border of monitoring area – IPC – Write/read data to/from block devices – Data transfer through remote computer

• Side-channel – File attributes, timings, …

16

for each symbol AsciiTable do if symbol = XTainted then YUntainted symbol end if end for

Whole system taint analysis can overcome some mentioned restrictions

Research of bugs / incidents

• IDA Pro disassembler leaves no alternative

17

Attack/defense Generations of protection vs. analysis tools

19

Manual analysis – disassemblers and debuggers

Anti-debugging, “naïve” static obfuscation, code protectors

Simulator + debugger Analysis automation: slicing,

deobfuscation

Simulator testing Further automation: symbolic

execution Improvement of obfuscation

Protection against symbolic execution

Compiler-built-in obfuscation Periodic obfuscation,

modification of interface and protocol ???

Protection against simulators Dynamic obfuscation

Code protection

Code analysis

Open issues

• How to combine warnings from static and dynamic analysis?

• No methods are known to build exploits capable of overcoming most of contemporary protection mechanisms

• Symbolic execution is great, but … – Exponential growth is unavoidable

– What to do with irreversible transformations?

– What to do with symbolic addresses?

– What to do with control dependencies?

• Two last points are also true for taint analysis

• … 20