[SOLVED] CS CSE 127: Introduction to Security

CSE 127: Introduction to Security
Memory safety and Isolation
George Obaido
Spring 2022 Lecture 5

Copyright By Assignmentchef assignmentchef

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) youre 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?
Whats 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 doesnt 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/readmemoryweshouldnthaveaccessto: 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 youre 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: assignmentchef QQ: 1823890830 Email: [email protected]