internet security 1 - eurecoms3.eurecom.fr/~aurel/syssec/syssec_5_memory_corruption.pdf · –...
TRANSCRIPT
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 15 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
• 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
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 14
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
• “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/
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
• 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
Stack Overflow: ADA Example
• 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
Are Vulnerabilities Caused by Bad Coding Practices?
• Good coding practices or safe languages definitely help, but it’s not a full solution– It can’t be always the fault of the developer– Developing without bugs is hard
Other Sources of Memory Corruption
• Buffer overflow is the classic attack• Can be caused by e.g., :
– Insufficient checking of input parameters– Integer overflows
• malloc(sizeof(X) *Y )
• There are many other source of corruption – Pointer arithmetic – Race conditions (last week)
– String format vulnerabilities (%n)
– Zero-sized malloc
– Null pointer dereference exploitation
• mostly kernel specific (will see an example)
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
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
• 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
• 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
• 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
• 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
• 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 possible scenarios :
1) No re-randomization– Probability of success after exactly t probes
– Expected number of probes:
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 !
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
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
Return Oriented Programming
sp
pc
• Code
Vulnerable function
Inst
ret
...
inst
ret
...
pop r1
ret
• Stack
array[0]
array[1]
array[2]
ret
...
Return Oriented Programming
sp
pc
• Code
Vulnerable function
Inst
ret
...
inst
ret
...
pop r1
ret
• Stack
X
X
X
@ret
val
@ret
@ret
val
@ret
Return Oriented Programming
sppc
• Code
Vulnerable function
Inst
ret
...
inst
ret
...
pop r1
ret
• Stack
X
X
X
@ret
val
@ret
@ret
val
@ret
Return Oriented Programming
sp
pc
• Code
Vulnerable function
Inst
ret
...
inst
ret
...
pop r1
ret
• Stack
X
X
X
@ret
val
@ret
@ret
val
@ret
Return Oriented Programming
sp
pc
• Code
Vulnerable function
Inst
ret
...
inst
ret
...
pop r1
ret
• Stack
X
X
X
@ret
val
@ret
@ret
val
@ret
Return Oriented Programming
sp
pc
• Code
Vulnerable function
Inst
ret
...
inst
ret
...
pop r1
ret
• Stack
X
X
X
@ret
val
@ret
@ret
val
@ret
Return Oriented Programming
sppc
• Code
Vulnerable function
Inst
ret
...
inst
ret
...
pop r1
ret
• Stack
X
X
X
@ret
val
@ret
@ret
val
@ret
Return Oriented Programming
sp
pc
• Code
Vulnerable function
Inst
ret
...
inst
ret
...
pop r1
ret
• Stack
X
X
X
@ret
val
@ret
@ret
val
@ret
Return Oriented Programming
sp
pc
• Code
Vulnerable function
Inst
ret
...
inst
ret
...
pop r1
ret
• Stack
X
X
X
@ret
val
@ret
@ret
val
@ret
Return Oriented Programming
• 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
Return Oriented Programming
• 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
• 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
• 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)
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…
• Other sources of errors ? Maybe
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 userland ● 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 exploits
Kernel 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 system :(
Bypassing countermeasures
Becomes harder :(
Limited kernel protection :)
From: A Guide to Kernel Exploitation, E. Perla, M. Oldani
Null Pointer Dereference
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 Dereference
• PAX UDREF : forbid dereference of user space addresses– Uses Segmentation, somehow deprecated
• Mainline Linux: Current solution is to prevent memory mapping below a threshold address – Dereferencing any pointer in user space ?
– How to detect dereference 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
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
• Allocation on stack – Too big array– Attacker controlled array
(C) John Oberhide
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
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
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 bufer overfow protection, S. Alexander, Usenix LOGIN;, June 2005.
• [Kern 10] A Guide to Kernel Exploitation, Enrico Perla, Massimiliano Oldani, Elsivier
• [Regehr05] Eliminating stack overfow 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 Efectiveness 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. Giufrida, CCS 2016