memory corruption vulnerabilities and counter...

Memory corruption Memory corruption vulnerabilities and vulnerabilities and counter measurescounter measures

Aurélien [email protected]

It’s quite an old field • Internet worm in 1988 (Moris)

– Was quite impressive, many techniques used

– Including

• Stack based buffer overflows

• Weak passwords brute-forcing

• “Zero-day” exploits

• Aleph One. Smashing the stack for fun and profit. Phrack Magazine 49(14), 1996. – Made the technique really popular

Interesting reads :– “A Tour of the Worm” Donn Seeley– “The Internet Worm Program: An Analysis” E. Spafford

Does it really matter?

• Attacks have been known since ~30 years – heavily exploited since 20 years

• Why isn’t the problem solved ? • Many solutions exists :

– Design software safely from the start

• Change language, use annotations– Compiler techniques – System level techniques

• None :– Solve all problems is used extensively– is practical enough– Are fully deployed

• Defensive counter-measures now largely deployed– Practical exploitation becomes often very hard

Overview

• Introduction and Motivation • Memory Corruption• Exploiting Memory Corruptions and Preventing

Exploitation• Advanced Techniques• Evading Interpreters• Some Kernel Exploitation Assorted Facts

MEMORY CORRUPTION

Terminology

• Memory corruption (safety/assumption violations)– Buffer Overflow

– Stack Overflow

– Integer Overflow– Use after free/ Double free– Null pointer dereference

• From Memory corruption to obtaining better control– Stack-based buffer overflow – Heap-based buffer overflow– Overflowing on non “control-data” memory

• From control of execution to actually doing something – Code injection on the stack (e.g., shellcodes)

– Code reuse techniques (Return to Libc, ROP)

} Directly leads to memory corruption

Often Indirectly leads to memory corruption

Depends...}

Syssec 8

Buffer Overflows

• A buffer overflow occurs any time a program attempts to store data beyond the boundaries of a buffer, overwriting the adjacent memory locations

• Result from mistakes done while writing code, because of

– unfamiliarity with language

– Lack of attention to the details

• Vulnerable software– mostly C / C++ programs

– not in languages with automatic memory management• dynamic bounds checks (e.g., Java)

• automatic resizing of buffers (e.g., Perl)

• But they often rely on libraries that are written in C (JNI)

Buffer Overflow 101

Buffer Overflow 101

• “Good candidates” for buffer overflows – String manipulation functions that don't properly check

string length (gets, strcpy, … )– Copy with incorrect parameters (memcpy …)– Incorrect computation of required memory length

• e.g. zero sized mallocs

Buffer Overflow 101

• Prevention mechanisms: – Strongly typed languages are less vulnerable – Specific functions from libc exist that makes it easier to

avoid mistakes

• e.g. strncpy : write at most N bytes

• strncpy(tmp_buff,src,sizeof(tmp_buf))

– Compiler extension to prevent some

• When array length can be computed by the compiler

– Annotations (e.g. Deputy, CCured…)

• We will see later some detection mechanisms

Integer overflows

• Integer Overflows: – Basic types have range limitations:

• 32 bits unsigned int – From 0 to 2^32-1 (4,294,967,295)

• 32 bits signed Int – from − (2^31) to 2^31 − 1

• Overflow : 4,294,967,295 + 1 =0– Some languages would throw an exception (Java, Ada...)– Many don't – Attacker can supply large values used in :

• Computation of the size of a buffer malloc'ed

• Array access (in particular the bound checks)

Integer overflow: example

• Code adapted from CVE-2011-1092, (a real world vulnerability)

• Call shmop_read ok:– shmop_read(10,10);– shmop_read(1,1);

• Call that fails :– shmop_read(1,2147483647);

• Int overflow on the check start+count>size

• Integer wraps around, actual compared value is :

(gdb) print start + count

$7 = -2147483648

All details available here http://xorl.wordpress.com/2011/03/12/cve-2011-1092-php-shmop_read-integer-overflow/

Integer overflow: the fix

• Check that integer does not overflow :– Start > (INT_MAX-count)

http://xorl.wordpress.com/2011/03/12/cve-2011-1092-php-shmop_read-integer-overflow/

Format String

What is wrong ? • Bad: printf (user_controlled_data);• Good: printf ("%s", user_controlled_data);

• Arguments pushed on the stack and interpreted, e.g.– printf(“%x”,1); will print the value 1– printf(“%x”); will print a value on the stack

• Format string manipulations : – Some formats are really dangerous: %n allows to write back

numbers of printed chars– Lots of variants and tricks – You will have to go into those details to solve one of the last

challenges:

“Exploiting Format String Vulnerabilities” scut / team teso, September 1, 2001, version 1.2

Stack Overflow ≠ Buffer Overflow ≠ Stack-Based Buffer Overflow

• Stack-based Buffer Overflows (will see)– often shortened as Stack Overflow– This is wrong and confusing

• Stack overflow :– the stack overflowing on adjacent memory sections

• Stack-based buffer overflow :– A buffer on the stack is overflowed, another variable is

overwritten

• Beware that most of the time you will see stack overflow written, it means stack based buffer overflows !– but not on my slides ;)

See https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash

Stack Overflow

• Stack Overflows can be caused by:– Recursive calls– Reentrant interrupts– Allocations on the stack

• Large• Controlled by the attacker• Alloca(), char array[function_parameter]

Stack Overflow

Stack Overflow

• This should never happen ?

• Detection : under Unix a guard page – Problem when allocation is too large

• the stack pointer can “jump over” the guard page

• Prevention: Not so easy– Abstract interpretation [Regehr05]

• Works as long as control flow can be determined statically

– Forbid / bound recursion – Forbid / limit allocation on the stack

• Without MMU ? – Serious problem on micro-controllers

Stack Overflow: ADA Example

• ADA is a strongly typed language– used for many years for critical systems (military,

spatial…) – Safe typing

• Example:– A function that allocates a local buffer

• on stack– Size determined by a parameter of the function

• If parameter controlled by the attacker – Exploitable stack overflow


• What a compiler usually does (e.g., Gnu ADA)

– Allocation on the stack • Subtracts the allocated size from the stack pointer• When memory is accessed page fault

– Allocate a page

– Dies on guard page

• Can jump over guard page

• Gnat from adacore:– “Allocates“ memory on stack page by page and touch

each page– Detects when guard page is reached

Stack Overflow: Multi-threading

• Multi-threading => multiple stacks• Example in an Asterisk exploit

– Alloca call that can be controlled by the attacker

– Two threads controlled (sockets)

• For more see– https://blog.exodusintel.com/tag/cve-2012-5976/

• GRSec Kernel patch that add a random space between pages allocated for stack (GRKERNSEC_RAND_THREADSTACK)

https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Insert_random_gaps_between_thread_stacks

Information leak

● An “Info leak” is a way to retrieve information that should not be “public” (not really memory corruption)

● E.g., dump memory from a process ● Retrieve pointers, stack layout, etc ● Various causes of info leaks:● Integer overflows, Buffer overflows (read)● Logic bugs, non initialized memory on allocation● String format bugs...● A non problem initially● apart in specific cases (OpenSSL private keys!)● https://xkcd.com/1354/● We will see that it now becomes increasingly useful against

countermeasures such as stack canaries and ASLR

https://blog.exodusintel.com/tag/cve-2012-5976/




• https://xkcd.com/1354/

Beyond Memory Corruption

• Finding a Vulnerability: the “Easiest” Part– We have a memory corruption bug

• Hopefully allowing arbitrary writes

• The rest of the lecture we will mainly cover what happens after the memory corruption– How does an attacker can exploit it– How can we defend against it

https://xkcd.com/1354/

EXPLOITING MEMORY CORRUPTIONSPREVENTING EXPLOITATION

Buffer Overflow: on the stackStack-based Buffer Overflow

• A special case of buffer overflow– The overflowed buffer is allocated

on the stack, typically corrupts ret addr

Buffer Overflow: on the stackStack-based Buffer Overflow

• Once the return address has been

modified the attacker has control of

the control flow

• Would “return” to :– The instructions ‘shellcode’ present

In the overflow

– Crafting shellcodes is an “art” lots of

tricks and docs on this

Control flow corruption

• Other possibility than modifying return address– Any function pointer

– GOT (Global offset table) …– C++ objects

• Control flow not always necessary – e.g., corrupt a variable that stores authentication status,

password to compare to...

Heap-based Buffer Overflows(often called Heap Overflows)

• Dynamically allocated data on the heap (e.g., malloc)

• Blocks of data are stored in a doubly linked list

typedef struct __HeapHdr__ {

struct __HeapHdr__ *next;

struct __HeapHdr__ *prev;

unsigned int size;

unsigned int used;

// Usable data area starts here

} HeapHdr_t;

• next/prev pointers are stored after the data – Overflow: overwrite the prev/next pointers

• Freeing a block (red is attacker controlled):– FD = hdr -> next– BK = hdr -> prev– FD->prev = BK– BK->next = FD

• This allows one arbitrary write at an

arbitrary address, e.g. function pointer• Detection is simple:

– if ( hdr->prev-> next == hdr)– canaries

Heap-based Buffer Overflows(often called Heap Overflows)

• Exploiting Heap overflows can be very complex• Need to predict the heap layout, control program

state… • … or do lead the program in the state where it is

exploitable

Heap-based Buffer Overflows

Summary of Heap related problems

• Heap-based buffer overflow – Overwrite adjacent memory chunk

• Double free / Invalid free– Free data that is not a valid allocated chunk

• Use-after-free– A pointer that was freed is cached and incorrectly used– Free the pointer => set it to zero, and all the aliases ?

After control flow corruption

• Where to execute from ?

• Inject instructions on the stack – Return to those– Called a shell code

• Not always easy to know the exact address – Using trampolines :

• jump *$esp at a fixed address– NOP slege

• A long sequence of NOP • Followed by the shellcode• Jumping anywhere in there leads to the shellcode

Finding a Vulnerability is the “Easiest” Part

• Nowadays programs and systems include counter-measures:– Stack Canaries– Address-Space Layout Randomization– Non executable memories (NX/DEP)– Compiler enforcement

• Next Slides :– A overview of those – Their limitations (i.e. new attacks !)

Stack Canaries

• Objective : Detect unexpected modifications of values on the stack (e.g., return address)

• Inserting a known value on the stack– the “canary”

• Compiler insert code that:– Add a random value after the

return address

Stack Canaries

• Objective : Detect unexpected modifications of values on the stack (e.g., return address)

• Inserting a known value on the stack– the “canary”

• Compiler insert code that:– Add a random value after the

return address – Checks canary value before using

return address

Stack Canary Limitations

• Sometimes it is possible to corrupt pointers – Write at the address they point to:

• E.g., after the canary• Fixed by using “Xor” canaries

• Canaries can be guessed or obtained with memory leaks

• Need good randomness• Canary copy need to be saved in a “safe” place ?

– Can it be corrupted as well ?

[Ale05] Defeating compiler-level buffer overflow protection => Overview of the limitations

W xor X (a.k.a.: NX/XN/DEP/PAX)Non Executable Memories

• Executable and writable memories regions– Used to be very common

– Allows to directly write instructions (in a buffer) and execute them, e.g., from the stack.

– Makes stack-based buffer overflows easy to exploit

• Most systems now support a form of NX:– Was complex on x86 (segmentation)

• HW support for it since ~2004

• Manufacturers find creative names for the same feature :– AMD : Enhanced Virus Protection,

– ARM : XN eXecute Never

• Defeated by Return-to-libc attacks / Return Oriented programming

Return to Libc

• NX makes it impossible to inject our own code and execute it.– No memory regions that are write and execute

• Idea : Reuse existing code – “Fortunately” libc loaded at a constant address – “Load” parameters on the stack– Jump to a known address

• Exec()

• For example:– Exec(“/bin/sh”)

ASLR: Address Space Layout Randomization

• Idea : We will make addresses sections of the program change at every load

• Randomize start or base address of:– Program code – Libraries code – Heap/Stack/Data regions – …

• Many programs have problems with that– Sometimes rewriting part of them is necessary – esp. when assembly code is present (e.g., optimized

media libraries)– Needs to be position independent code for program

randomization

ASLR: Limitations

• Memory leaks used to “learn” memory layout– Local /proc/ file system– Remote memory leaks, uninitialized data

• Address space / system limitations: e.g., pages boundaries– x86: 32 bits => 16 bits of randomization

• 32768 probes in general => brute force • Re-randomizing between probes adds only 1-bit of

difficulty

– This is worse on 16 bit embedded systems !– 64 bit architectures are more resistant

Re-randomizing Between Probes

2 possible scenarios :

1) No re-randomization– Linear search trough addresses

– Or Sampling without replacement problem

2) Re randomize between each probe– Randomizing more than once between 2 probes is pointless

– Sampling with replacement

Let n be the number of bits to guess– There are 2^n possible layout randomizations, one

is correct

“On the Effectiveness of Address-Space Randomization”, Hovav Shacham, et. al

Re-randomizing Between Probes

2) Re randomize between each probe:

a sampling with replacement problem.

● Every attempt we have the same chance (probability) of finding the good layout

● p=1/2^n● Expectation is 1/p = 2^n

● Difference between with and without re-randomization is: 2^n / 2^n-1 = 2

● This is 1 bit of entropy

Usage in Practice

• Supporting the couple NX/ALSR/Canaries – makes attacks much harder– Is not always the case !

• Isn’t bullet proof !

Usage in Practice: “Hardened“ server

Usage in Practice: Ubuntu Desktop

Other interesting tools

• Paxtest– An utility from PAX project that tests features

• Evaluates entropy of ASLR

• Similar on Windows – Looking Glass

Usage in Practice: Windows

Also see http://0xdabbad00.com/wp-content/uploads/2013/11/emet_4_1_uncovered.pdf

Usage in Practice: EMET

• EMET is a hardening tool for windows XP– Other systems have them by default.

http://0xdabbad00.com/wp-content/uploads/2013/11/emet_4_1_uncovered.pdf

(MORE) ADVANCED TECHNIQUES

Borrowed Code Chunks

• Was first developed for return-to-libc attacks on X86-64

• Parameters are passed in registers instead of stack

• Find sequences of instructions such as – Pop r1– Ret

• Chain them to load registers• Jump to the function• Several such function calls can be chained

together

Return Oriented Programming

• Return-to-libc is limited to the available/existing functions

• Can we find sequences of instructions that allows to perform some given operations?

• “Chain” them together ? – Called Gadgets

• A Turing complete set of gadgets allows to perform arbitrary computation– Showed to work on most architectures– Equivalent to having a virtual machine/interpreter


sp

pc

• Code

Vulnerable function

Inst

ret

...

inst

ret

...

pop r1

ret

• Stack

array[0]

array[1]

array[2]

ret

...


sp

pc

• Code

Vulnerable function

Inst

ret

...

inst

ret

...

pop r1

ret

• Stack

X

X

X

@ret

val

@ret

@ret

val

@ret


sppc

• Code

Vulnerable function

Inst

ret

...

inst

ret

...

pop r1

ret

• Stack

X

X

X

@ret

val

@ret

@ret

val

@ret


sp

pc

• Code

Vulnerable function

Inst

ret

...

inst

ret

...

pop r1

ret

• Stack

X

X

X

@ret

val

@ret

@ret

val

@ret


sppc

• Code

Vulnerable function

Inst

ret

...

inst

ret

...

pop r1

ret

• Stack

X

X

X

@ret

val

@ret

@ret

val

@ret


sp

pc

• Code

Vulnerable function

Inst

ret

...

inst

ret

...

pop r1

ret

• Stack

X

X

X

@ret

val

@ret

@ret

val

@ret


• Automating generation of return oriented payloads :– Compiler C=>ROP

• On the x86 “unintended” instructions– Decoding an instruction in the middle may be decoded as

another instruction

• ROP Allows to “execute” arbitrary code

• As long as we:– Know the memory map (no ASLR)– Find interesting gadgets– Chain them in a given order


• Automation techniques to find those sequences of code – Satisfiability Modulo Theories (SMT) Solvers

• Mainly Bit vectors theories• => Immunity debugger

• Translation assembly => intermediate instructions Language– Intermediate instructions no side effects– Gadget search Independent of target assembly language– Riel tool/language

• Several public tools for this

Return Oriented ProgrammingImmunity debugger

• Converts assembly into constraints• Add specific constraints for the gadget to be found

• SMT solver solves the logic problem

• Attach process • Find gadgets

– !gadgets Secur32.dll

• Locate “stack pivot” change stack pointer to attacker data– !findpivot

• Finding gadgets with specific constraints– !find_gadget -g secur32.dll_5.1.2600.5834_gadgets.pkl -d EAX

-v 0x0

Return Oriented Programming:Countermeasures

Ideas:• Removing “return” instructions from programs • Checking coherency of call/returns

But ROP can be performed using only indirect jumps [SHA10]

• Protecting returns does fully solve the problem…

• Compiler based solution [G-Free]– Checks for presence of required gadgets – “free branch” instructions

• Abadi et al. Control Flow integrity

Return Oriented Programming:Impact

It’s not only about code injection attacks only !

• Malicious code detection cannot be limited to executable memory regions– Return oriented rootkits / malicious code…

• Integrity checks• Even non executable memories needs to be verified• Difficulty : data cannot be known in advance :

Reboot ?

ROP defeated by ASLR … chaining returns needs to know addresses in advance

Methods to Bypass NX+ASLR

• Information leak – e.g. return uninitialized data to the attacker

• e.g. printf(“%s”);

– This allows to know addresses of potential gadgets

• Increasing chances of hitting the shellcode

• ARMs Race – e.g. WIN 7 new “defense”

• system calls check stack pointer location

• With ROP stack pointer often in strange locations

• Bypassing is easy: change SP before calling such functions

Blind ROP

• When Address space layout randomization is in place it is difficult to know where are the gadgets ! Or when the executable is unknown

• It is possible to learn where are the gadgets, brute force and monitor side effects

• Stack learning overwrite a byte at a time and bruteforce it.

EVADING INTERPRETERS

“Evading” Interpreters

• Techniques to bypass ASLR and/or NX• In many cases the attacks are performed

– From a malicious webpage – Can execute javascript or flash content– Then abuse a vulnerability

• Heap spraying • JIT spraying • Pointer inference

Heap Spraying

1st Step • Javascript code will allocate many objects • Those objects contain:

– “Nop sledge” (many instructions that do nothing)

– Attack payload

2nd Step – Abuse vulnerability (e.g., stack based buffer overflow)– Return execution to an approximate address in the heap

– “Some” likelihood to work

– 32 bits address space, “spray” 100MBytes in the heap • Chance to jump on a nop slege 1/30

Heap Spraying

• This increase the chances to jump to the shellcode, even with ASLR in place

https://www.corelan.be/index.php/2011/12/31/exploit-writing-tutorial-part-11-heap-spraying-demystified/

Heap Spraying

Picture from https://www.corelan.be

Heap Spraying

• When the heap is not executable – “Should” always be the case, but it is not

• ROP to a stack pivot – Move stack pointer to the heap– This requires to know address of instructions used by the

ROP

JIT Spraying

• JIT (Just In Time compilation) :– At runtime detect CPU intensive functions,

– Compile it to native code mark it executable and execute it

– Huge speed-up

• There are many interpreters that rely on JIT– e.g.,: Java, JavaScript, Flash/action script …

• From the attacker point of view :– JIT Transforming Data into Code

– Then immediately executes this code ( => page marked executable!)

– The code generation phase is predictable

• JIT Spraying : force the JIT compiler to compile code for the attacker !

• Just in time code reuse (JIT-ROP)



EXPLOITING SOFTWARE WHEN NO REAL BUG IS THERE

Software exploitation will always be possible

• Software built for one purpose • Attacker missuses the software for another purpose

– Through inputs etc…

• Turing machines (weird machines):– Gives expressive power – Can be found in file formats and unexpected places:

• ELF (WooT 2013, Shapiro et al.)

• Page fault handlers (WooT 2013, Bangert et al.)

Software exploitation will always be possible: hardware

Fault injection:

• Perturbating the execution environment during code execution – errors can be focused and abused (Laser, Power supply glitch, clock glitch). Commonly

used to break smart cards.

• Cosmic rays leads to random errors:– Domains with bit flips? Bitsquatting (Artem Dinaburg, BH2011) : register domains with

one bit error in the name:

• e.g., microsmft.com

• DRAM access/refresh rate insufficient: RowHammer– Particular memory access patterns lead to bit errors in DRAM– Can be triggered from Javascript, on ARM and Intel, needs to bypass caches…

• Speculative execution (meltdown, spectre)– Will have a dedicated lecture on this soon.

• Other sources of errors ? Maybe

SOME KERNEL EXPLOITATION ASSORTED FACTS

What is a Kernel after all

• A Kernel is code that:– Is privileged – Executes because interrupts or system calls– Isolates processes from each other– Handles hardware and provides services

● Rather large and complex code● Rather protected from user land ● Mandatory for the system, easy to “panic”

Linux Kernel Specifics

Under Linux: user address space / kernel address space

0x00000000

0x80000000

0xC0000000

0xFFFFFFFF

User space

Kernel space

Linux Kernel Specifics

• Kernel level programming is usually more difficult than user space programming, – Until recently it was the case for exploitation as well

• Writing exploits in user land is much harder now with userland counter-measures

• Attacking kernel becomes (relatively) easier

• Stack canaries Ok• ASLR Not a great idea• NX Ok

Userland vs Kernel land Attempt to User land

exploitsKernel land exploits

Brute force Multiple crashes but OK ;)

Panic and Reboot :(

Influence target Locally a lot of control :)

Other apps also interact :(

Execute shellcode

Can use syscalls :)

Has to return cleanly to the user land :(

Bypassing countermeasures

Becomes harder :(

Limited kernel protection :)

From: A Guide to Kernel Exploitation, E. Perla, M. Oldani

Null Pointer De-reference

A real world example:

A= Null…B=*A;If ( A == null)

Goto abort

Use B

• 2 problems :– Userspace map a page at address 0 – Gcc optimization removed the “useless check”

Null Pointer De-reference

• PAX UDREF : forbid de-reference of user space addresses– Uses Segmentation, somehow deprecated

• Mainline Linux: Current solution is to prevent memory mapping below a threshold address – De-referencing any pointer in user space ?

– How to detect de-reference of other invalid pointers ?

Null Pointer Dereference

• Intel introduced a HW mechanism to prevent kernel mode to access user mode data:– SMEP (Supervisor Mode Execution Protection Enable)– SMAP (Supervisor Mode Access Protection Enable)

• See: – http://vulnfactory.org/blog/2011/06/05/smep-what-is-it-and

-how-to-beat-it-on-linux/– https://forums.grsecurity.net/viewtopic.php?f=7&t=3046

Current memory mappings (post meltdown)

Two Pages tables for each process (instead of one)

0x00000000

0xC0000000

0xFFFFFFFF

0x80000000

Kernel space

User spaceUser space(smap/smep protected)

Linux Kernel Specifics: Stack Overflow

• Kernel code can be executed in two modes:– Interrupt context– User context (system call)

(C) John Oberhide

Linux Kernel Specifics Stack Overflow

• User context – Thread info is stored on the stack

Linux Kernel Specifics Stack Overflow

• Allocation on stack – Too big array– Attacker controlled array

(C) John Oberhide

http://vulnfactory.org/blog/2011/06/05/smep-what-is-it-and-how-to-beat-it-on-linux/

http://vulnfactory.org/blog/2011/06/05/smep-what-is-it-and-how-to-beat-it-on-linux/

https://forums.grsecurity.net/viewtopic.php?f=7&t=3046

KASLR: Kernel Address Space Layout Randomization

• Idea: ASLR makes attacks against applications more difficult– Lets do the same for the kernel ! But does not really improve

security…

– Multiple attacks, mainly cache side channels which can be improved because of problems in x86 architecture

• Transactional memory (TSX)

• Prefetches, memory mappings

From : “Breaking Kernel Address Space Layout Randomization with Intel TSX”, Y. Jang, S. Lee, T. Kim, CCS 2016

Control Flow Integrity

CFI: Control flow integrity

• Aims to guaranty the control flow – Execution flow

• Can be performed by:– verifying backward edges (integrity of return addresses)

– Verifying forward edges (call and jumps)

• Backward: (shadow stack), labels for returns (legitimate return sites)• Forward: labels for forward edges (legitimate jumps/calls)

• Both at the same time possible but slow (fine grained) • Coarse grained approaches (guaranty jumps are within function bounds)

faster but vulnerable to attacks• Binary v.s. source based approaches

Strict CFI can still be exploited

• Non control data attacks have been known for long time (Hen et al “Non-control-data attacks are realistic threats” USENIX Security 2005)

• Control flow bending attacks: change control flow but stay on plausible paths

• Data flow attacks: do not change the CFI at all

• An attacker can abuse legitimate control flow:– By manipulating data to control program’s behavior

• e.g., an interpreter

– By corrupting data flow

Example Clang CFI

• Clang is a C/C++ compiler from LLVM toolchain– Has an option to harden CFI -fsanitize=cfi– Forward edge only– Backward edge (returns) at design stage

Automation

Can we (fully) automate exploitation ?

• NDSS 2011– Using static analysis, SMT solvers, concolic

interpretation, preconditionned abstract interpretation– Checking properties

Can we (fully) automate exploitation ?

• Limitations – This only allows to detect some forms of vulnerabilities – Creates an exploit, but assuming no NX/ASLR/Canaries– Do not allow to actually build a working exploit that would

bypass security measures on modern operating systems

• This remain an “art”

● 2016 Cyber Grand Challenge: fully automated CTF Game (simplified OS model)

● Rapidly evolving techniques

Next lecture

Next Week: ●Trusted computing and software based attestation

●Acknowledgements:● As usual those slides include some material from ●Engin Kirda●Davide Balzarotti

References

• [Ale05] Defeating compiler-level buffer overflow protection, S. Alexander, Usenix LOGIN;, June 2005.

• [Kern 10] A Guide to Kernel Exploitation, Enrico Perla, Massimiliano Oldani, Elsivier

• [Regehr05] Eliminating stack overflow by abstract interpretation. J. Regehr, A. Reid, and K. Webb. Trans. on Embedded Computing Sys., 4(4), 2005.

• [CAN 05] Large memory management vulnerabilities; system, compiler, and application issues G. Delalleau. CanSecWest 2005

• [ACSAC 10] G-Free : defeating return-oriented programming through gadget-less binaries Onarlioglu, Kaan; Bilge, Leyla; Lanzi, Andrea; Balzarotti, Davide; Kirda, Engin (ACSAC'10)

• [CERTC]The CERT C Secure Coding Standard, Robert C. Seacord Addison-Wesley

• [ SHA04] On the Effectiveness of Address-Space Randomization H. Shacham et al., CCS 2004

References

• [GFree] G-Free : defeating return-oriented programming through gadget-less binaries, Onarlioglu, Kaan; Bilge, Leyla; Lanzi, Andrea; Balzarotti, Davide; Kirda, Engin, ACSAC 2010.

• [SCUT] “Exploiting Format String Vulnerabilities” scut / team teso, September 1, 2001, version 1.2

• “Hacking Blind” Andrea Bittau, Adam Belay, Ali Mashtizadeh, David Mazieres, Dan Boneh; Oakland 2014

• “Breaking Kernel Address Space Layout Randomization with Intel TSX”, Y. Jang, S. Lee, T. Kim, CCS 2016

• “Prefetch Side-Channel Attacks: Bypassing SMAP and Kernel ASLR” D. Gruss, C. Maurice, A. Fogh, M. Lipp, S. Mangard, CCS 2016

• “Drammer: Deterministic Rowhammer Attacks on Mobile Platforms”, V. van der Veen, Y. Fratantonio, M. Lindorfer, D. Gruss, C. Maurice, G. Vigna, H. Bos, K. Razavi, C. Giuffrida, CCS 2016

memory corruption vulnerabilities and counter...

Documents