exploits against software and defences

Exploits Against Software and Defences

Nicolas T. Courtois - University College London

Reading

Nicolas T. Courtois, January 20092

How to Break Into Computers?

• Stack attacks: Chapter 10.4.• SQL injection: not at the exam: see our lab.• Defences: Chapter 10.7.

Nicolas T. Courtois, January 20093

Is that All?

There is MUCH more (not covered here): • Language Based Security COMPGS10 course (Term 2)…• Government agencies and hackers have found

LOTS of software security holes, – AUTOMATION, formal methods– Requires source code (cf. Common Criteria evaluations)– Example: in just one Huawei Chinese router firmware experts found 10 000 unsafe

calls to the sprintf function alone…

Main Learning Objective: Understand the principal sources of attacks and what the defences are.

Goals of Attackers

CompSec COMPGA01

Nicolas T. Courtois, December 20095

Break In

Stage 1: Get to run some code (even without

privileges).

Stage 2: Gain admin access, usually by calling other

local programs and exploiting their vulnerabilities.

CompSec COMPGA01


Later…

• create a backdoor for later access

• cover your traces– e.g. disable anti-virus, erase log files, etc…

• payload: execute extra tasks

CompSec COMPGA01


Goals for Software Exploits

• crash software (can be DOS)• crash hardware (e.g. hard drive)• get some data or side channels• inject arbitrary code

these also happen accidentally…

What’s Wrong?

CompSec COMPGA01


Software Vulnerabilities

1. Input validation problems2. Buffer overflow3. Format string vulnerabilities4. Integer overflows, 5. CPU bugs6. Failing to handle errors / exceptions properly7. etc…

Vectors of Attack - Inputs

CompSec COMPGA01


Software Input Exploits

Exe programs:• command line arguments• environment variables• configuration files / settings changed in the

registry by another program…

• network packets• etc…

Dlls / Unix runtime precompiled libraries:• function calls from other programs

CompSec COMPGA01


Danger of Environment Variables

In UNIX: • Set LD_LIBRARY_PATH system variable

to avoid the standard precompiled libraries…• Hacker puts his own libraries in his own

directory…

BTW. Fix: modern C runtime libraries in Unix stopped using LD_LIBRARY_PATH at least in many cases…

CompSec COMPGA01


Revision: set-uid programs

Def: A “set-uid program” (property acquired at install) is a program that assumes the identity and has euid and privileges of the owner of the program,

though a different user runs it.

Examples: • passwd• su, sudo

BTW: if copied to a “user” directory, stop working!

CompSec COMPGA01


More Attacks on PATH in Unix

Now imagine that any “setuid program” contains the following line:

system(“ls … ”);

OOPS…

there are several ways to use this to run any program as root…

CompSec COMPGA01


More Attacks on PATH in Unix

A “setuid program” ABC contains the following line:

system(“ls …”);

The user sets his PATH to be =“.” and places his own program ls in the current directory.

This program ls will be run as root.

(remark: the program A can reset PATH or do checks on PATH(remark: the program A can reset PATH or do checks on PATH……))

CompSec COMPGA01


Another Known Exploit in Unix

• The IFS variable: the characters that the system considers as white space

• now add “s” to the IFS set of characters

– system(ls) becomes system(l)– a function l in the current directory will be

run as root…

CompSec COMPGA01


Can this be done remotely?

• In PHP language, used by all web servers, they have PASSTHRU() function that executes arbitrary code…

• Assume it contains a user input that comes from the web client browser.

• insert “; command231” or “| command231”.• This will make the server execute command231

and output the result to the web page displayed.

PHP have later banned this and many other things from the PHP language…

Buffer Overflow

CompSec COMPGA01


Software Buffer Overflow Exploits

I will explain in details only 1 type of code injection attack…

“Buffer Overflow through Stack Smashing”

There are many other types of software vulnerabilities…

Study of these requires a lot of technical expertise about programming, compilers, assembly and CPUs…

Discovery of new attacks is like a 1 G$ project: it requires:source code + formal methods + maths + software solver technology + lots of experimentation + machine learning + extensive knowledge of what’s out there etc.

CompSec COMPGA01


Buffer Overflow History

Extremely common since the 1980s.

Consistently about 50 % of all CERT advisories still in late 2000s…

Usually leads to a total compromise of the machine…

CompSec COMPGA01


Can Programmers Get It Right?

Lot of evidence around that they cannot.• the behavior of Turing machines is very HARD to analyse,

– cf. Rice thm.

• it is usually easier to rewrite code from the scratch than to find all bugs in it, open source software was like a virus…

• software economics, time to market, code re-use etc…

Major problems also occur at the compiler and runtime level…

(even CPUs have bugs that can be used for exploits).

CompSec COMPGA01


Problems with C and C++

• C and C++ particularly dangerous– Fast, therefore used in servers and all critical

code (fast data manipulation, crypto and security functions)

– allows arbitrary manipulation of pointers • but not outside the virtual 2 Gbyte space allocated by

the OS

CompSec COMPGA01


Problems with C and C++

• Memory Safety = a restriction on copying data from one memory location to another, except for if types clearly allow assignments.

– closely related to type safety: …preventing type cast and copy data that don’t have the same type.

– Java and C# offer (imperfect) memory safety.• hard to prove, actually shown not quite true for Java

CompSec COMPGA01


**Dangling Pointers

= pointers that do not point to a valid object in the program

For example in C use malloc, realloc and free, Then the pointer is not automatically reset to NULL.

Good practice is to do it manually all the time.

CompSec COMPGA01


Software Under Attack

Main goal: inject arbitrary code through standard input channels of the program.

Input-dependent vulnerabilities. Excessively common in software we use every day… Unix and Windows alike…

CompSec COMPGA01


Exploit = specially crafted input

that allows a certain task to be accomplished compromising the security policy usually executing arbitrary code.

Goal: execute with the privilege level of the program:

• web server running as superuser…• Ordinary programs running as user…

Furthermore, injected code may use another vulnerability to permit privilege escalation.

Buffer Overflow Attack:Stack Smashing and Code Injection in C

CompSec COMPGA01


Buffer Overflow in C

char command[256]=“”;allocated from the stack.

Now imagine we input longer data than 256 bytes and use strcpy(command,*input_data).

In theory: “undefined behaviour”..In practice: we can predict what will

happen.

CompSec COMPGA01


historical roots

Since ever, in CPU assembly and in compiling structured programs, the habit is to save the state of the CPU when calling a sub-routine.

And saving the return address.It is essential which comes first…

otherwise there would be no such attack.

This is saved on the process stack.

CompSec COMPGA01


Process Memory Layout

Stack

Grows toward low memory

Heap

Grows toward high memory

Text

• Text: loaded from exec code and read-only datasize fixed at size fixed at compilationcompilation

• Heap: runtime allocated objects, large (2 Gb)large (2 Gb)

• Stack: LIFO, holds function arguments and local variables, small size (256 K)small size (256 K)

0xC0000000

0x40000000

0x08048000

CompSec COMPGA01


Calling a Sub-Routine in C

Stack

PUSH PULL

on every

CPU since ever…

Stack Stack

CompSec COMPGA01


Stack Frames for one C Function f

Stack Stack Stack

params of f

return address

saved bottom of stack

local variables

built in this order

CompSec COMPGA01


exploit on f

Stack

params of f

return address


local variables increasing addresses

void f(params){

char command[256]=“”;

…

strcpy(command,sth)}

size easy to guess

overwrite

CompSec COMPGA01


exploit on f

Stack

params of f

return address


local variables increasing addresses

void f(params){

char command[256]=“”;

…

strcpy(command,sth)}

easy to guess

overwriteshell code

0x80707050

CompSec COMPGA01


when f finishes

Stack

params of f

return address


local variables

return address

shell code

0x80707050

the frame buffer was de-allocated, data

still there

CompSec COMPGA01


Is It Easy?• for strcpy() avoid 0’s in exploit code.• predict the size of all local variables.

– IMPORTANT: does never need an exact value.• patch with many NOP instructions to work for a range of

addresses… • put several copies of

the new return address

• must be able to predict the stack address.– not hard for simple programs…

– open source: MUCH easier to attack. – many copies of the same program – easier.

• this is how Slammer infected 75 K MS-SQL servers.

shell codeNOP slide

CompSec COMPGA01


Reliabilityup to very high,

up to 100% (there are stable exploits,

never ever failand produce consistent

results)

What Hackers Do?

CompSec COMPGA01


Finding ExploitsClosed source:• try at random with long inputs ending by $$$$• if the program crashes, look at core dumps for $

$$’s• later use debuggers and disassemblers to

design precise exploits…

Open source: • easier!

Hackers have automated tools for finding exploits…

CompSec COMPGA01


ExampleWith XBox 360 Microsoft made it very hard to

install other OS, like Linux.

Why? The console sale price was subsidized by Microsoft. Legitimate reason (!).

Hackers found a buffer overflow attack on James Bond 007 game when it restored from saved game, to take over the boot loader…

Very impressive…

CompSec COMPGA01


***Ethical Code Injection Exists?Wikipedia:code injection can "trick" the system into behaving in a

certain way without any malicious intent. Code injection could, for example:

• introduce a useful new column that did not appear in the original design of a search results page.

• offer a new way to filter, order, or group data by using a field not exposed in the default functions of the original design.

Someone might resort to this sort of work-around because … software … becomes too frustrating or painful.

Some developers allow or even promote the use of code injection to "enhance" their software, usually because this solution offers a less expensive way to implement new or specialized features…

Can We Fix It?

CompSec COMPGA01


Solutions (1)• use type and memory safe languages (Java, ML)• clean the de-allocated frame buffer: slow!!!

Partial solutions (not perfect)• certain forms of access control?

– yes, replace pointers by use of “un-forgeable reference” tokens

• sandboxing and “secure” VM techniques.• store things in a different order:

ASLR = Address Space Layout Randomisation – at the runtime!– suddenly it makes a lot of sense to recompile the Apache web server

software on each server. Reason: 75 K copies, Slammer worm.• OpenBSD (enabled by default)• Linux – weak form of ASLR by default since kernel 2.6.12. (much better with the Exec Shield patch for

Linux).• Windows Vista and Windows Server 2008:

– ASLR enabled by default, although only for those executables and dynamic link libraries specifically linked to be ASLR-enabled. So only very few programs such as Internet Explorer 8 enable these protections…

CompSec COMPGA01


Solutions (2)Automated protections with canaries:

store known data at the end of the buffer. Check. • StackGuard, ProPolice, PointGuard = extensions of GCC, automatic.

• similar protections also by default since MsVisual Studio 2003.

Time performance overhead: about +10%.

Is this secure?• Can the attacker predict the canary?

• Can he learn it from several exploit attempts?

CompSec COMPGA01


CanariesTwo types known:• random canaries: known but random data canaries

• terminator canaries: not the same at all, special ‘terminator’ values

• \0 to stop strcpy()• {newline} + {linefeed} to stop fgets()• EOF to stop fread()…

– can combine all these after each buffer

CompSec COMPGA01


One Attack Against StackGuard and Canaries

CompSec COMPGA01


Solutions (3)• hire a programmer with extensive understanding of

software attacks– less attacks, will not eliminate them

Cheaper solutions:• make sure that stack space is marked as impossible

to execute ()– NX bit + Windows DEP = Data Execution Protection. – Linux W X : text pages: X, not W, data (stack, heap) pages: W,

not X

• blacklist parts of C language! – ongoing process.

CompSec COMPGA01


Bypassing DEP ? Yes!• only prevents simple injection

of assembly code on the stack…• can inject some other sort of code…

– like system calls + parameters that will contain instructions for the shell (!!!).

• The simplest example: – System(“command123”)

• Details depend a lot on OS and installed software.

– Modern versions: call some API, some dll, OS routines to disable DEP or manage memory etc…

Stack

return address


local variablesshell code

0x80707050

command123

system()

CompSec COMPGA01


Preventing Attacks on System Calls

• Can we prevent the exploits with Windows dlls?

• Answer: In Windows, at boot time the order and location of system calls WILL be randomised.

• Lowers considerably the chances to succeed,(does not eliminate the attack) Stack

return address


local variablesshell code

0x80707050

command123

ms*.dll

CompSec COMPGA01


Input Validation• Application-specific: check if intended

length and format.– use special encoding for inputs– use encrypted inputs, check length

• the attack is unlikely to do anything intended? – If stream cipher, can flip bits to change one character…

• Routines that remove dangerous characters.– In PHP, using the htmlentities() function.– In an SQL request, use

mysql_real_escape_string()

CompSec COMPGA01


C Tips – Replace by

sprintf(buf, …) snprintf(buf, buflen, …),

scanf(“%s”, buf) scanf(“%10s”, buf),

strcpy(buf, input) strncpy(buf, input, 256)

etc…

CompSec COMPGA01


Solutions (4)Automated tools working on:Source code:

– Coverity: test trust inconsistency.– Microsoft program analysis group:

• PREfix: looks for fixed set of bugs (e.g. null ptr ref)• PREfast: local analysis to find prog errors.

– [Wagner, et al. @ Berkeley]: Test constraint violations.

These find lots of bugs, but not all.

Ready exe:• Taintcheck: fix ready exe files…

– At runtime mark memory locations as tainted by user data.– Slow. Up to 25x.

• Web servers cost lots of $$$, cannot afford to do it..

CompSec COMPGA01


Solutions (5)Replacement libraries:Example: libsafe – dynamically linked library,

will intercept calls to strcpy and check buffer sizes..

StackShield – an assembler file processor for GCC

• keeps backup copies of SFP and RET at the beginning of local variables, compare before exiting the function.

CompSec COMPGA01


Solutions (6)Instruction Set Randomization (ISR) – runtime

encryption of CPU instructions… different for each program, makes code injection impossible.

Has been done.• not widely used.• network-intensive applications run smoothly• CPU-intensive applications: 20x slower

*Heap Overflow:

consider as home reading, not at the exam

CompSec COMPGA01


Process Memory Layout

Stack

Grows toward low memory

Heap


Text

• Text: loaded from exec code and read-only datasize fixed at size fixed at compilationcompilation

• Heap: runtime allocated objects, large (2 Gb)large (2 Gb)

• Stack: LIFO, holds function arguments and local variables, small size (256 K)small size (256 K)

0xC0000000

0x40000000

0x08048000

CompSec COMPGA01


Right Proportions

Not always this area is a heap.

It can be fragmented.More generally term

“heap exploits” refers to all kinds of attacks on data structures dynamically allocated/freed within RAM.

Stack

Heap


Text

can take most of the 2-4 Gbytes

space

CompSec COMPGA01


InsightsHow Memory Management is implemented?(harder to design a working attack, less

standard than stack attacks…)

Implemented by a compiler through its standard dynamic libraries, example: msvc*.dll that contain executable already compiled functions.

Main idea: the design of these memory management routines can be exploited. How? A bit complex.

CompSec COMPGA01


InsightsHeap managers have linked lists with

forward/backward pointers, sizes, and data fields.

CompSec COMPGA01


What the attacker can do?

A simple buffer overrun (works only forwards):

• can contain code chosen by the attacker. and if heap is marked NX, pointers to libc functions + parameters in and if heap is marked NX, pointers to libc functions + parameters in the following bytes..the following bytes..

• plus extra bytes that will overwrite the “malloc meta data” for the next 3 blocks

= the prev/next pointers in these blocks, • overwritten by values chosen by the

attacker…

shell code

CompSec COMPGA01


What the attacker can do?

What happens when the routine freeing the memory is called?

On this picture, allocations 1 and 2 are already freed, which maybe happens a bit later during the same function call… The next step is to merge these two free blocks. Why?

shell code

CompSec COMPGA01


Concatenation after free()Defragmentation is important: otherwise allocation of large blocks might fail and the program

would terminate with an out of memory message though there is plenty of memory left…

This mechanism is typically automatic and sometimes is also done with a certain delay, but frequently will be called before the current C or C++ function exits…

hdrnext = hdrnextnext

hdrnextnextprev = hdrnextprev

shell code

CompSec COMPGA01


InsightsIn heap attacks none of these addresses will

ever be used as jump address. Seems hopeless?

It is more subtle than that. What we do is to overwrite a return address elsewhere. On the stack. By abusing this specific “defragmentation” method/routine, when it is called (immediately or later).

The attacker can control both:• the address where a certain pointer

will be written automatically by the heap Mgmnt

• the value of this pointer to be overwritten

shell code

hdrnext = hdrnextnext

CompSec COMPGA01


InsightsSuppose I override these links to point • hdrnext = to the return address of

the function on the stack. • hdrnextnext = a pointer to code

(probably just in the buffer I overran)

When the heap manager merges the two blocks, it will actually overwrite the return address on the stack with a pointer to code I control.

This will be called after the current function exits.

shell code

exploits against software and defences

Documents

compsec compga01nicolas

setuid program

setuid program property

function calls

stack attacks

modern c runtime libraries

path system variable

principal sources of