ln. 6 buffer overflow attacks (2) · pdf file 2019-10-06 · contents buffer...

Click here to load reader

Post on 25-Jul-2020




1 download

Embed Size (px)


  • Operating Systems Security

    LN. 6

    Buffer Overflow Attacks (2)

    Computer Security & OS lab.

    Cho, Seong-je (조성제)

    sjcho at dankook.ac.kr

    Fall, 2019

  • Contents

     Buffer Overflows: Stack Smashing, Heap overflow, Global data overflow

    ● Background knowledge: Little endian vs. Big endian, Assembly language, …

    References & Source (Credit):

    ● Lecture: Code-reuse attacks and defenses, Lucas Davi, University of Duisbure-Essen

    ● Code-Reuse Attacks and Defenses, MSc. Lucas Vincenzo Davi, Technische Universitat Darmstadt

    ● Computer Security, Principles and Practice, 3rd ed., William Stallings & Lawrie Brown

    ● EECS710: Information Security, Professor Hossein Saiedian, Fall 2014, Electrical Engineering and Computer Science, KU

    ● Return-Oriented Programming, David Brumley, CMU

    ● Introduction to Information Security, 0368-3065, Spring 2016, Control Hijacking, Avishar Wool, Tel Aviv University

    ● CAP6135: Malware and Software Vulnerability Analysis, Buffer Overflow I & II: Attack/Defense, Cliff Zou, Spring 2012/2014, UCF

    -2-Computer security & OS lab, DKU

  • Basic Execution

    -3-Computer security & OS lab, DKU

  • Buffer Overflow (= Buffer Overrun)

     Buffer Overflow by NIST’s Definition (NIST Glossary of Key Information Security Terms)

    ● “A condition at an interface under which more input can be placed into a buffer or data holding area than the capacity allocated, overwriting other information.

    − Attackers exploit such a condition to crash a system or to insert specially crafted code that allows them to gain control of the system.”

    ● Overwriting adjacent memory locations

    ● A buffer overflow occurs when data is written outside of the space allocated for the buffer.

    − C does not check that writes are in-bound

    ● Where can a buffer be located?

    -4-Computer security & OS lab, DKU

  • Brief History of Buffer Overflow Attacks

     Buffer overflow is a very common attack mechanism

    ● from 1988 Morris Worm to Code Red, Slammer, Sasser and many others

    -5-Computer security & OS lab, DKU

  • Buffer Overflow & Programming Language

     A Little Programming Language History

    ● At machine level, all data are stored in an array of bytes

    − interpretation depends on instructions used

    ● Modern high-level languages have a strong notion of type and valid operations

    − not vulnerable to buffer overflows

    − does incur overhead, some limits on use

    ● C and related languages have high-level control structures, but allow direct access to memory

    − hence are vulnerable to buffer overflow

    − have a large legacy of widely used, unsafe, and hence vulnerable code

    -6-Computer security & OS lab, DKU

  • Buffer Overflow Attacks

     To exploit a buffer overflow an attacker needs:

    ● must identify a buffer overflow vulnerability in some program

    − Identifying vulnerable programs can be done by:

    • Inspection of program source

    • tracing the execution of programs as they process oversized input

    • Using tools such as fuzzing to automatically identify potentially vulnerable programs

    ● understand how buffer is stored in memory and determine potential for corruption

     Consequences: ● unexpected transfer of control

    ● memory access violation

    ● execution of code chosen by attacker

    -7-Computer security & OS lab, DKU

  • Vulnerable APIs and Target programs in Buffer Overflows

     Safer functions

    ● strncpy, snprintf, strncat

    ● fgets

    -8-Computer security & OS lab, DKU

    Table 10.2 Some Common Unsafe C Standard Library Routines

    gets(char *str) read line from standard input into str

    sprintf(char *str, char *format, ...) create str according to supplied format and variables

    strcat(char *dest, char *src) append contents of string src to string dest

    strcpy(char *dest, char *src) copy contents of string src to string dest

    vsprintf(char *str, char *fmt, va_list ap) create str according to supplied format and variables

     Some Common Unsafe C Standard Library Routines

    ● strcpy()  strncpy()  strlcpy()

  • Linux strings command

    -9-Computer security & OS lab, DKU

  • x86 Assembly language on AT&T vs. Intel

    -10-Computer security & OS lab, DKU

     AT&T syntax, which is the default for objdump, uses ,

    Mnemonic Meaning

    mov ebx, eax Move contents of ebx into eax

    add ebx, eax Calculate eax = eax + ebx

    shl $2, ecx Calculate ecx = ecx

  • Big-endian vs. Little-endian

     Big-endian (POWER family): Linux on SPARC, PowerPC, and z/Architecture, Mac OS X on Power PC

     Little-endian (x86 family): Linux/Windows on x86, x64, and Itanium

    -11-Computer security & OS lab, DKU -11-Computer security & OS lab, DKU

  • Buffer Overflows

     Advantages ● very effective

    − attack code runs with privileges of exploited process

    ● can be exploited locally and remotely

    − interesting for network services

     Disadvantages ● architecture dependent

    − directly inject assembler code

    ● operating system dependent

    − use call system functions

    ● some guesswork involved (correct addresses)

    -12-Computer security & OS lab, DKU

  • Overflow Types

     Overflow memory region on the stack ● overflow function return address

    ● overflow function frame (base) pointer

    ● overflow longjump buffer

     Overflow (dynamically allocated) memory region on the heap

     Overflow function pointers ● stack, heap, BSS

    -13-Computer security & OS lab, DKU

  • Defense against Buffer Overflow Attacks

    • Programming Language Level

    • Library Level

    • Compiler Level

    • Run-time Level

    Computer security & OS lab, DKU -14-

  • Programming language & Program static analyzer

     Programming language ● Java and Python

    − Provide automatic boundary checking against buffer overflow

     Program static analyzers ● They warn developers of the patterns in code that may lead to buffer

    overflow vulnerabilities

    − The goal is to notify developers early in the development cycle of potentially unsafe code in their programs

    ● E.g.)

    ITS4, ARCHER (Array CHeckER), BOON (Buffer Overrun detectiON), RATS,

    Flawfinder, PolySpace C Verifier, SPLINT (Secure Programming Lint),

    UNO(Uninitialized variables, dereferencing Nil-pointers, and Out-of-bound array indexing)

    -15-Computer security & OS lab, DKU

  • Compiler-level countermeasures

     StackGuard

    ● The idea is to put a guard between the return address and the buffer

    ● Compiler adds a random value below the return address and saves a copy of the random value (referred to as the canary) at a safer place that is off the stack.

    ● Before the function returns, the canary is checked against the saved value.

     Stackshield

    ● The idea is to save a copy of the return address at some safer place.

    ● At the beginning of a function, the compiler inserts instructions to copy the return address to a location (a shadow stack)

    ● Before returning from the function, additional instructions compare the return address on the stack with the one that was saved

    -16-Computer security & OS lab, DKU

  • Non Executable Address Space (Run-time defense)

     Many BO attacks copy machine code into buffer and transfer control to it

     Use virtual memory support to make some regions of memory non- executable (to avoid exec of attacker’s code)

    ● e.g. stack, heap, global data

    ● need H/W support in MMU

    ● long existed on SPARC/Solaris systems

    ● recent on x86 Linux/Unix/Windows systems

     The adversary can only inject his malicious code, but cannot execute it

     Issues: ● support for executable stack code

    − Some apps need executable stack (e.g. LISP interpreters)

    ● Special provisions are needed

    -17-Computer security & OS lab, DKU

  • Marking memory as non-execute (W⊕X)

    Prevent attack code execution by marking stack, heap, data as non-executable.

    (von Neumann architecture ⇒ Harvard-based computing architecture) – Harvard architecture: code and data are strictly separated from each other

    • AMD: NX-bit (“No Execute”, from AMD Athlon 64) Intel: XD-bit (“Executable Disable”, from Intel P4 Prescott)

    – NX bit in every Page Table Entry (PTE)

    • Modern OSes enable W⊕X by default (Windows, Linux, iOS, Android):

    – Linux (via PaX project); OpenBSD – Windows: since XP SP2 (“DEP”(Data Execution Prevention))

    • Boot.ini : /noexecute=OptIn or AlwaysOn

    • Visual Studio: /NXCompat[:NO]

    • Limitations: – Some apps need executable heap (e.g. JITs).

    – Does not defend against `return-to-libc’ exploits

    -18-Computer security &