CSE 127: Introduction to Security
Memory safety and Isolation
George Obaido
Spring 2022 Lecture 5
Copyright By PowCoder代写 加微信 powcoder
Some slides from , , , , , , , , and
Buffer overflow mitigations
• Avoid unsafe functions: Strcmp, strcpy, gets, etc → Memory writable or executable, not both (W^X)
• Address space layout randomization
W^X: write XOR execute
• Goal: Prevent execution of shell code from the stack • Insight: Use memory page permission bits
• Use MMU to ensure memory cannot be both writeable and executable at the same time
• Many names for same idea:
• XN: eXecute Never
• W^X:WriteXOReXecute
• DEP: Data Execution Prevention
Recall our memory layout
user stack
shared libs
runtime heap
static data segment
text segment
rx %ebp rw %esp
Recall our memory layout
user stack
shared libs
runtime heap
static data segment
text segment
hijacked ret
rx %ebp rw %esp
W^X tradeoffs
• Easy to deploy: No code changes or recompilation • Fast: Enforced in hardware
• Downside: What do you do on embedded devices?
• Some pages need to be both writeable and executable • Why?
How can we defeat W^X?
• Can still write to return address stored on the stack • Jump to existing code
• Search executable for code that does what you want
• E.g. if program calls system(“/bin/sh”) you’re done • libc is a good source of code (return-into-libc attacks)
Address Space Layout Randomization (ASLR)
• Traditional exploits need precise addresses • stack-based overflows: shellcode
• return-into-libc: library addresses
• Insight: Make it harder for attacker to guess location of shellcode/libc by randomizing the address of different memory regions
How much do we randomize? 32-bit PaX ASLR (x86)
ASLRTradeoffs
• Intrusive: Need compiler, liker, loader support • Process layout must be randomized
• Programs must be compiled to not have absolute jumps • Incurs overhead: Increases code size and performance
• Also mitigates heap-based overflow attacks
When do we randomize?
Many options.
• At boot?
• At compile/link time? • At run/load time?
What’s the tradeoff?
• Not useful for forensic analysis
How can we defeat ASLR?
• -fno-pie binaries have fixed code and data addresses • Enough to carry out control flow hijacking attacks
• Each region has random offset, but layout is fixed
• Single address in a region leaks every address in region
• Return-orientedprogramming • Heapcorruption
• Isolation
Return-Oriented Programming (ROP)
• Idea:makeshellcodeoutofexistingcode
• Gadgets:codesequencesendinginretinstruction
• Overwrite saved %eip on stack to pointer to first gadget, then second gadget, etc.
Return-Oriented Programming
• Idea:makeshellcodeoutofexistingcode
• Gadgets:codesequencesendinginretinstruction
• Overwrite saved %eip on stack to pointer to first gadget, then second gadget, etc.
• Wheredoyouoftenfindretassemblyinstructions? • End of function (inserted by compiler)
One ret, multiple gadgets
b8 01 00 00 00 5b c9 c3 =
mov$0x1,%eax pop %ebx leave
One ret, multiple gadgets
b8 01 00 00 00 5b c9 c3 =
add %al,(%eax) pop %ebx
One ret, multiple gadgets
b8 01 00 00 00 5b c9 c3 =
add %bl,-0x37(%eax) ret
One ret, multiple gadgets
b8 01 00 00 00 5b c9 c3 =
pop %ebx leave ret
One ret, multiple gadgets
b8 01 00 00 00 5b c9 c3 =
One ret, multiple gadgets
b8 01 00 00 00 5b c9 c3 = ret
• Attackeroverflowsstackallocatedbuffer • Whathappenswhenfunctionreturns?
• Restore stack frame
• leave = movl %ebp, %esp; pop %ebp
• ret =pop %eip
• Ifinstructionsequenceat%eipendsinretwhatdowe do?
What happens if this is what we overflow the stack with?
pop %edx ret
relevant stack:
relevant register(s):
%edx = 0x00000000
0xdeadbeef
0x08049bbc
relevant code:
%eip 0x08049b62: nop 0x08049b63: ret
0x08049bbc: pop %edx 0x08049bbd: ret
relevant stack:
relevant register(s):
%edx = 0x00000000
0xdeadbeef
0x08049bbc
relevant code:
0x08049b62: nop
%eip 0x08049b63: ret …
0x08049bbc: pop %edx 0x08049bbd: ret
relevant stack:
relevant register(s):
%edx = 0x00000000
0xdeadbeef
0x08049bbc
relevant code:
0x08049b62: nop
0x08049b63: ret …
%eip 0x08049bbc: pop %edx 0x08049bbd: ret
relevant stack:
relevant register(s):
%edx = 0xdeadbeef
0xdeadbeef
0x08049bbc
relevant code:
0x08049b62: nop
0x08049b63: ret …
0x08049bbc: pop %edx %eip 0x08049bbd: ret
This is a ROP gadget!
pop %edx ret
movl v1, %edx
How do you use this as an attacker?
• Overflowthestackwithvaluesandaddressestosuch gadgets to express your program
• e.g.ifshellcodeneedstowriteavalueto%edx,usethe previous gadget
Can express arbitrary programs
Can find gadgets automatically
How do you mitigate ROP?
Observation: In almost all the attacks we looked at, the attacker is overwriting jump targets that are in memory (return addresses and function pointers).
• One ROP mitigation could be a Address Space Layout Randomization (ASLR)
• Return-orientedprogramming → Heap corruption
• Isolation
Memory management in C/C++
• Cusesexplicitmemorymanagement
• Data is allocated and freed dynamically
• Dynamic memory is accessed via pointers
• Youareonyourown
• If system does not track memory liveness
• If system doesn’t ensure that pointers are live or valid
• Bydefault,Chassameissues
• Dynamicallyallocateddatastoredonthe “heap”
• HeapmanagerexposesAPIforallocating and deallocating memory
• malloc() and free()
• API invariant: All memory allocated by malloc() has to be released by corresponding call to free()
Heap management
• Organizedincontiguouschunksofmemory
• Basic unit of memory
• Can be free or in use
• Metadata: size + flags
• Allocated chunk
• Heaplayoutevolveswithmalloc()sandfree()s
• Chunks may get allocated and freed
• Freechunksarestoredindoublylinkedlists(bins)
• Different kinds of bins: fast, unsorted, small, large, …
How can things go wrong?
• Forgettofreememory
• Write/readmemoryweshouldn’thaveaccessto: Overflow code pointers on the heap
• Useafterfree:Usepointersthatpointtofreedobject • Doublefree:Freealreadyfreedobjects
Most important: heap corruption
• Canbypasssecuritychecks(data-onlyattacks) • e.g. isAuthenticated, buffer_size, isAdmin, etc.
• Canoverwriteheapmanagementdata
• Corrupt metadata in free chunks
• Program the heap weird machine
Use-after-free in C++
Victim: Free object: free(obj);
Attacker: Overwrite the vtable of the object so entry
(obj->vtable[0]) points to attacker gadget Victim: Use dangling pointer: obj->foo()
Dangling pointers and memory leaks
• Dangling pointer: Pointer points to a memory location that no longer exists
• Memory leaks (tardy free) Memory in heap that can no longer be accessed
Dangling pointer
int main(){
int *arr1 = malloc(sizeof(int));
*arr1 = 2;
printf(“%d/n”, *arr1)
free(arr1);
arr1 = NULL //Solution: Set to Null return 0;
Memory Leak
int main(int argc, char *arg[]){
int *arr1 = malloc(sizeof(int));
*arr1 = 2;
printf(“%d/n”, *arr1) free(arr1);//solution: free the memory or
deallocate the memory arr1 = NULL
Heap exploitation mitigations
• Safeheapimplementations
• Safe unlinking
• Cookies/canaries on the heap
• Heap integrity check on malloc and free
• UseRustorasafegarbagecollectedlanguage, such as Julia, Ruby, etc.
What does all this tell us?
If you’re trying to build a secure system, use a memory and type-safe language.
• Understandbasicprinciplesforbuildingsecuresystems • Understandmechanismsusedtobuildsecuresystems
Running untrusted code
We often need to run buggy or untrusted code.
Running untrusted code
We often need to run buggy or untrusted code.
• Desktopapplications
• Mobileapps
• Untrustedusercode
• Websites,Javascript,browserextensions • PDFviewers,emailclients
• VMsoncloudcomputinginfrastructure
Systems must be designed to be resilient in the face of vulnerabilities and malicious users.
Principles of secure system design
• Leastprivilege
• Privilegeseparation • Completemediation • Failsafe/closed
• Defenseindepth
• Keepitsimple
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com