Embed Size (px)
Citation preview
Intel ME
Intel ME
Intel ME how bad is it ?
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
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 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
Buffer Overflow 101
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)
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
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
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
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
• 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 !
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
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
“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
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…
• 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 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
• 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
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
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 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
