Introduction Buffer Overflows Buffer overflows were the most common - - PDF document

▶

Oct 07, 2022 605 likes •656 views

Introduction Buffer Overflows Buffer overflows were the most common form of security vulnerability in the 90s. Buffer overflows dominate in the area of remote network penetration vulnerabilities. CS 465 They represent one of the

SLIDE 1

1

CS 465 Fall 2001 1

Buffer Overflows

CS 465

Dr. Kent E. Seamons

Source: “Buffer Overflows: Attacks and Defenses for the Vulnerability of the Decade” Cowan et al.

CS 465 Fall 2001 2

Introduction

♦ Buffer overflows were the most common

form of security vulnerability in the 90’s.

♦ Buffer overflows dominate in the area of

remote network penetration vulnerabilities.

♦ They represent one of the most serious

classes of security threats.

– An attacker can gain partial or total control of a host

CS 465 Fall 2001 3

Buffer Overflow Attacks

♦ Form the substantial portion of all security

attacks

– Common – Easy to exploit ♦ Dominate remote penetration attacks – 1998 CERT advisories, 9 of 13 – 1999 CERT advisories, 50 % – Bugtraq survey: 2/3 reported buffer overflows a leading cause of security vulnerability

CS 465 Fall 2001 4

Buffer Overflows

♦ Goal of buffer overflow – Subvert the function of a privileged program to take control of the program – If the program is sufficiently privileged, thence control of the host – Typically the attacker is attacking a root program, and immediately executes code similar to “exec(sh)” to get a root shell

CS 465 Fall 2001 5

Buffer Overflows - Goals

♦ Arrange for suitable code to be available in

the program’s address space

♦ Get the program to jump to that code, with

suitable parameters loaded into registers & memory

CS 465 Fall 2001 6

Load Code in Program’s Address Space

♦ Inject code ♦ Use code already in program’s address

space

SLIDE 2

2

CS 465 Fall 2001 7

Inject code in Address Space

♦ Attacker provides a string as input to the program,

which the program stores in a buffer.

♦ The string contains bytes that are native CPU

instructions

– The attacker does not have to overflow any buffers to do this – Buffer can be located anywhere

Stack (automatic variables)
Heap – (malloc’d variables)
Static data area (initialized or uninitialized)

CS 465 Fall 2001 8

Use existing program code

♦ Often, the code to do what the attacker

wants is already present in the program’s address space (“exec(arg)”)

♦ The attacker need only parameterize the

code and jump to it

CS 465 Fall 2001 9

Ways to Cause the Program to Jump to the Attacker’s Code

♦ Alter the program’s control flow so that the

program will jump to the attack code

♦ Basic method: overflow a buffer that has weak or

non-existent bounds checking on its input with a goal of corrupting the state of an adjacent part of the program’s state

♦ The attacker overwrites the adjacent program state

with a near arbitrary sequence of bytes

♦ Bypass of C’s type system and the victim

program’s logic

CS 465 Fall 2001 10

Kind of Program State Overflowed

♦ Activation records ♦ Function pointers ♦ Longjmp pointers

CS 465 Fall 2001 11

Activation Records

♦ Created on the stack when a function is

called

♦ Overflow automatic variables ♦ Corrupt the return address in the activation

record

♦ “Stack smashing attack” ♦ Majority of current buffer overflow attacks

CS 465 Fall 2001 12

Function Pointers

♦ Function pointers can be allocated

anywhere

♦ Attacker finds an overflowable buffer

adjacent to a function pointer in any of these areas

♦ Change the function pointer

SLIDE 3

3

CS 465 Fall 2001 13

Longjmp Buffers

♦ Checkpoint/rollback facility in C ♦ Checkpoint – “setjmp(buffer)” ♦ Rollback – “longjmp(buffer)” ♦ Attacker can corrupt the state of the buffer

so that longjmp will jump to the attacker’s code

CS 465 Fall 2001 14

Combining Code Injection and Control Flow Corruption

♦ The simplest and most common form of overflow

combines an injection technique and activation record corruption in a single string –stack smashing attack

♦ The injection and corruption do not have to

happen in one action

– An overflowable buffer may have incorrect bounds checking, so there is a limit on the overflow that does not give the attacker enough room to store the code – The attacker is using already-resident code

libc code fragments (exec(something))

CS 465 Fall 2001 15

Buffer Overflow Defenses

♦ Write correct code ♦ Non-executable buffers ♦ Array Bounds checking ♦ Code pointer integrity checking

CS 465 Fall 2001 16

Write Correct Code

♦ A laudable but expensive proposition – C language has error-prone idioms such as null- terminated strings and a culture that favors performance

ver correctness

♦ Automatic search of source code for highly

vulnerable library calls

♦ Program linking warning messages ♦ Audit teams that review code by hand – lprm program had an error following a code audit

CS 465 Fall 2001 17

Non-executable buffers

♦ Make the data segment of a program’s address

space non-executable

– Older computing systems followed this design – Unix and MS

Windows depend on the ability to emit

dynamic code into program data segments ♦ One can make the stack segment non-executable

and preserve most program compatibility

– Kernel patches available for Linux and Solaris ♦ Linux exceptions to executable code on the stack – Signal delivery – gcc trampolines – fallen into disuse

CS 465 Fall 2001 18

Array Bounds Checking

♦ Completely stops buffer overflows ♦ All reads and writes to arrays must be checked ♦ Compaq C compiler – Limited bounds checking ♦ Gcc patch – Not mature, complex programs fail ♦ Purify – Code instrumentation – Imposes a 3 to 5 times slowdown ♦ Type safe languages

SLIDE 4

4

CS 465 Fall 2001 19

Type Safe Languages

♦ All buffer overflows result from a lack of

type safety in C

♦ Recommendation: write new security

sensitive code in a type safe language such as Java or ML

– Millions of lines of legacy code – The JVM is a C program, subject to buffer

verflow vulnerabilities

CS 465 Fall 2001 20

Code pointer integrity checking

♦ Instead of preventing corruption of code pointers,

try to detect a code pointer has been corrupted before it is de-referenced

♦ Disadvantages – Does not perfectly solve the buffer overflow problem ♦ Advantages – Performance – Compatibility – Implementation effort

CS 465 Fall 2001 21

Code Pointer Integrity

♦ Hand-coded stack inspection ♦ Compiler-generated activation record

integrity checking

♦ Compiler-generated code pointer integrity

checking

CS 465 Fall 2001 22

StackGuard

♦ Compiler technique implemented as a small patch

to gcc that enhances code generation for the code to setup and tear down functions

♦ Places a canary word next to the return address on

the stack

♦ The code checks to see that the canary word is

intact before jumping to the return address

♦ Invariant – the return address should not change

while a function is active

CS 465 Fall 2001 23