1 / 17

Lecture 8: Use and Abuse of the Stack

This lecture covers runtime stack, heap, data, and text/shared libraries. It also discusses memory referencing bugs, buffer overflows, and defending against buffer overflow attacks.

jrodrigues
Download Presentation

Lecture 8: Use and Abuse of the Stack

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 8: Use and Abuse of the Stack CS 105 February 18, 2019

  2. Stack • Runtime stack (8MB limit) • E. g., local variables • Heap • Dynamically allocated as needed • When calling malloc(), calloc(), new() • Data • Statically allocated data • E.g., global vars, staticvars, string constants • Text / Shared Libraries • Executable machine instructions • Read-only x86-64 Linux Memory Layout 7FFFFFFFFFFF Stack 8MB Heap Data Text 000000000000

  3. Stack Frames 0x7FFFFFFF Stack • Each function called gets a stack frame • Passing data: • calling procedure P uses registers (and stack) to provide parameters to Q. • Q uses register %rax for return value • Passing control: • call <proc> • Pushes return address onto stack • Sets %rip to first instruction of proc • ret • Pops return address from stack and places it in %rip • Local storage: • allocate space on the stack by decrementing stack pointer, deallocate by incrementing … Arguments 7..n local variables return address Arguments 7..n return address saved registers local variables 0x00000000

  4. Results are system specific Memory Referencing Bug Example typedefstruct { int a[2]; double d; } struct_t; double fun(inti) { volatile struct_t s; s.d = 3.14; s.a[i] = 0xC0000000; return s.d; } fun(0) ➙ 3.14 fun(1) ➙ 3.14 fun(2) ➙3.140001 fun(3) ➙-2.000001 fun(4) ➙ 3.14 Segmentation fault

  5. Memory Referencing Bug Example typedefstruct { int a[2]; double d; } struct_t; fun(0) ➙ 3.14 fun(1) ➙ 3.14 fun(2) ➙3.140001 fun(3) ➙-2.000001 fun(4) ➙ 3.14 Segmentation fault Explanation: Location accessed by fun(i) struct_t

  6. Example: server.c

  7. Generally called a “buffer overflow” • when exceeding the memory size allocated for an array • Why a big deal? • It’s the #1 technical cause of security vulnerabilities • #1 overall cause is social engineering / user ignorance • Most common form • Unchecked lengths on string inputs • Particularly for bounded character arrays on the stack • sometimes referred to as stack smashing Such Problems are a BIG Deal

  8. Buffer overflow bugs can allow remote machines to execute arbitrary code on victim machines • Distressingly common in real programs • Programmers keep making the same mistakes  • Recent measures make these attacks much more difficult • Examples across the decades • Original “Internet worm” (1988) • “IM wars” (1999) • Twilight hack on Wii (2000’s) • Jailbreaking iPhones (since 2007) • … and many, many more Exploits Based on Buffer Overflows

  9. Exploited a few vulnerabilities to spread • Early versions of the finger server (fingerd) used gets()to read the argument sent by the client: • finger droh@cs.cmu.edu • Worm attacked fingerd server by sending phony argument: • finger “exploit-code padding new-return-address” • exploit code: executed a root shell on the victim machine with a direct TCP connection to the attacker. • Once on a machine, scanned for other machines to attack • invaded ~6000 computers in hours (10% of the Internet!) • see June 1989 article in Comm. of the ACM • the young author of the worm was prosecuted… • and CERT (Computer Emergency Response Team) was formed Example: the original Internet worm (1988)

  10. Worm: A program that • Can run by itself • Can propagate a fully working version of itself to other computers • Virus: Code that • Adds itself to other programs • Does not run independently • Both are (usually) designed to spread among computers and to wreak havoc Aside: Worms and Viruses

  11. Avoid overflow vulnerabilities • Insert compiler checks • Employ system-level protections Defending against buffer overflow attacks

  12. Buffer Overflow Vulnerabilities

  13. For example, use library routines that limit string lengths fgets instead of gets strncpy instead of strcpy Don’t use scanf with %s conversion specification Use fgets to read the string Or use %nswhere n is a suitable integer 1. Avoid Overflow Vulnerabilities in Code (!) /* Echo Line */void echo(){ char buf[4]; /* Way too small! */fgets(buf, 4, stdin); puts(buf);}

  14. Idea • Place special value (“canary”) on stack just beyond buffer • Check for corruption before exiting function • GCC Implementation • -fstack-protector • Now the default (disabled earlier) 2. Compiler checks 0x7FFFFFFF Stack … Arguments 7..n local variables return address Arguments 7..n return address saved registers local variables unix>./bufdemo-protected Type a string:0123456 0123456 unix>./bufdemo-protected Type a string:01234567 *** stack smashing detected *** 0x00000000

  15. Stack Frame Example overflow: subq    $40, %rsp movq    %fs:40, %rax movq    %rax, 24(%rsp) xorl    %eax, %eax movl    $10, 12(%rsp) movq    %rsp, %rdi   call    proc movq    24(%rsp), %rdx xorq    %fs:40, %rdx je      .L3   call    __stack_chk_fail .L3: addq    $40, %rsp   ret int proc (int *p); int overflow (int x) { int a[4]; a[3] = 10;  return x + proc(a); } Listing produced with gcc –S -Ogstackcheck.c

  16. 3. System-level Protection: Memory Tagging W X

  17. Next time! Code-Reuse Attacks

More Related