Countermeasures against Buffer Overflow Attacks: Prevention and Detection Techniques, Slides of Software Engineering

Download Countermeasures against Buffer Overflow Attacks: Prevention and Detection Techniques and more Slides Software Engineering in PDF only on Docsity!

Buffer Overflow II: Defense Techniques

Countermeasures

• We can take countermeasures at different

points in time

• before we even begin programming
• during development
• when testing
• when executing code
• to prevent, to detect – at (pre)compile time or

at runtime -, and to migitate problems with

buffer overflows

Prevention

• Don’t use C or C++ (use type-safe language)
  • Legacy code
  • Practical?
• Better programmer awareness & training
  • Building Secure Software, J. Viega & G. McGraw, 2002
  • Writing Secure Code, M. Howard & D. LeBlanc, 2002
  • 19 deadly sins of software security, M. Howard, D LeBlanc & J. Viega, 2005
  • Secure programming for Linux and UNIX HOWTO, D. Wheeler, www.dwheeler.com/secure-programs
  • Secure C coding, T. Sirainen www.irccrew.org/~cras/security/c-guide.html

Dangerous C system calls source: Building secure software, J. Viega & G. McGraw, 2002

Prevention – use better string libraries

• there is a choice between using statically vs

dynamically allocated buffers

• static approach easy to get wrong, and chopping user input may still have unwanted effects
• dynamic approach susceptible to out-of-memory errors, and need for failing safely

Better string libraries

• libsafe.h provides safer, modified versions of eg strcpy
• strlcpy (dst,src,size) and strlcat (dst,src,size ) with size the size of dst, not the maximum length copied. - Used in OpenBSD
• glib.h provides Gstring type for dynamically growing null- terminated strings in C - but failure to allocate will result in crash that cannot be intercepted, which may not be acceptable
• Strsafe.h by Microsoft guarantees null-termination and always takes destination size as argument
• C++ string class
  • data() and c-str()return low level C strings, ie char*, with result of data()is not always null-terminated on all platforms...

Dynamic countermeasures

• Protection by OS kernel
  • Non-executable stack memory (NOEXEC)
    • prevents attacker executing her code
  • Address space layout randomisation (ASLR)
    • generally makes attacker's life harder
      • E.g., harder to get return address place and injected code address
• Protection inserted by the compiler
  • to prevent or detect malicious changes to the stack
• Neither prevents against heap overflows

Marking stack as non-execute

• Basic stack exploit can be prevented by marking stack segment as non-executable - Then injected code on stack cannot run - For most programs, there is no need to have any code in stack memroy - Code patches exist for Linux and Solaris - E.g., our Eustis machine’s Ubuntu has enabled Non-executable stack protection - To complete our project 1, the vulnerable code “target.c” needs to compile by disabling this function - gcc -z execstack -o target target.c

Address Randomization Techniques

• For successful exploit, the attacker needs to know where to jump to, i.e., - Stack layout for stack smashing attacks - Heap layout for code injection in heap - Shared library entry points for exploits using shared library
• R andom i zation Techniques for Software Se curity
  • Randomize system internal details
    • Memory layout
    • Internal interfaces
  • Improve software system security
    • Reduce attacker knowledge of system detail to thwart exploit
    • Level of indirection as access control

Randomize Memory Layout (I)

• Randomize stack starting point
  • Modify execve() system call in Linux kernel
  • Similar techniques apply to randomize heap starting point
• Randomize heap starting point
• Randomize variable layout

Randomization in Ubuntu

• Linux Ubuntu has implemented by default
• For project 1, we have to disable it in attack

and target code

• setarch i686 -R ./exploit

Dynamic countermeasure: stackGuard

• Solution: StackGuard
  • Run time tests for stack integrity.
  • Embed “canaries” in stack frames and verify their integrity prior to function return.

Canary Types

• Additional countermeasures:
  • use a random value for the canary
  • XOR this random value with the return address
  • include string termination characters in the canary value (why?)

• StackGuard implemented as a GCC patch
  • Program must be recompiled
• Low performance effects: 8% foR Apache
• Problem
  • Only protect stack activation record (return address, saved ebp value)