Fundamentals of Linux Platform Security

Transcription

1 Fundamentals of Linux Platform Security Security Training Course Dr. Charles J. Antonelli The University of Michigan 2012

2 Linux Platform Security Module 8 Arbitrary Code Execution: Threats & Countermeasures

3 Buffer Overflows

4 Linux Architecture User Process Process Process Process Process Process Process Process Process Kernel VFS UFS NFS RPC/XDR TCP/IP Security Memory Manager Scheduler Communication Drivers 4

5 Process Memory 0xFFFFFFFF Stack Virtual Addresses Heap Uninitialized Data Initialized Data 0x Code 5

6 Linux Architecture Creating a process Two intertwined system calls A parent process calls fork() Creates a child process» An exact copy of the parent» Including uid, open files, devices, network connections The child process calls exec(executable) Overlays itself with the named executable» Retains uid, open files, devices, network connections 6

7 Linux Architecture Creating trouble exec() may be called without fork() Useful paradigm tcpd execs the wrapped application after validation So what happens if a process calls exec("/bin/sh")? Process becomes a command shell Running with the overlaid process's credentials» If the process was running as root, so is the shell Connected the same network connections» If the process was connected to your keyboard, so is the shell» If the process was connected to a client, so is the shell 7

8 Smashing the stack Part I A calling function will write its return address into a memory data structure called the stack When the called function is finished, the processor will jump to whatever address is stored in the stack Suppose Local Variable 1 is an array of integers of some fixed size Suppose our called function doesn t check boundary conditions properly and writes values past the end of the array The first value beyond the end of the array overwrites the stack The second value overwrites the return address on the stack When the called function returns, the processor jumps to the overwritten address 8

9 Smashing the stack 0xFFFFFFFF Virtual Addresses 0x Parameter 3 Parameter 2 Parameter 1 Return Address Saved FP Local Variable 1 Local Variable 2 RA FP SP 9

10 Smashing the stack 0xFFFFFFFF Virtual Addresses 0x Parameter 3 Parameter 2 Parameter 1 Return Address Saved FP Value Local Variable 2 RA FP SP 10

11 Smashing the stack 0xFFFFFFFF Virtual Addresses 0x Parameter 3 Parameter 2 Parameter 1 Return Address Value Value Local Variable 2 RA FP SP 11

12 Smashing the stack 0xFFFFFFFF Virtual Addresses 0x Parameter 3 Parameter 2 Parameter 1 Value Value Value Local Variable 2 RA FP SP 12

13 Smashing the stack 0xFFFFFFFF Virtual Addresses 0x Parameter 3 Parameter 2 Value Value Value Value Local Variable 2 RA FP SP 13

14 Smashing the stack Part II Suppose the attacker has placed malicious code somewhere in memory and overwrites that address on the stack Now the attacker has forced your process to execute her code Where to place the code? Simplest to put it in the buffer that is being overflowed How to get the code into the buffer? Examine the source code Look for copy functions that don t check bounds» gets, strcpy, strcat, sprintf, Look for arguments to those functions that are under the attacker s control and not validated by the victim code» Environment variables, format strings, URLs, 14

15 Blaster (variant) Worm Blaster used a buffer overflow attack against the Microsoft RPC server We ll inspect a trace of a Blaster infection Real data, filtered and anonymized Who can spot the shellcode? 15

16 History An unpatched Windows laptop was brought to U-M and connected to the wireless network At home, it lived comfortably behind a firewall Connected at 19:30:13 Infected at 19:41:13 Noticed by HackFinder a day or so later Attack traffic captured by a packet vault 16

17 Details Lab materials cd /usr/local/lab/blaster Contains compressed libpcap format trace file Hint: it s not necessary to uncompress the entire trace file, and don t try to use Wireshark Attack information Victim IP = Attacker IP = Victim connected 19:30:13 Victim infected 19:41:13 View Blaster documentation on class Web site Find and characterize the attack! 17

18 Countermeasures Avoiding buffer overflows Prevent them from occurring Preventing buffer overflows Assume you can t avoid them Trap the attempt, and recover Recovering from buffer overflows Assume you can t avoid them Detect that it has happened, and recover 18

19 Avoidance Requires code analysis and review Some automation is possible Manual process so it is expensive And what about the code you don t write? so it will never be complete (Not so) recent progress here Many vulnerabilities closed Increased developer awareness & avoidance tools Phishing and pharming can be more lucrative 19

20 Prevention Non-executable stack W^X (OpenBSD) Random-offset stack Random-offset libraries (Not so) recent progress here 20

21 Recovery Canaries StackGuard ProPolice/SSP Pointer encryption Guard pages Electric Fence 21

22 Problems Beyond stack smashing Heap smashing Pointer subterfuge Function-pointer clobbering Data-pointer clobbering Exception-handler hijacking VPTR smashing 22

23 Problems Beyond stack smashing Arc injection return-to-libc -> return-to-lib -> chained return-tolib -> borrowed code chunks -> return-oriented programming (ROP) Turing-complete malicious computations using borrowed chunks of existing code Automated Defenses? Another arms race 23

24 Future Smashing attacks will be with us for some time, because of Hardware architecture Programming language Co-location of function arguments and return address exec() 24

25 References Matt LeGrow, "Blasting 'Blaster' - Detecting the MSRPC DCOM hole," Rapid Response Team, NFR, Inc. Retrieved January Aleph One, "Smashing the Stack for Fun and Profit," Phrack Magazine, Vol. 7, Iss. 49, Kaan Onarlioglu et al, G-Free: Defeating Return-Oriented Programming through Gadget-less Binaries, ACM ACSAC 10, Austin, December (retrieved February, 2012) 25