Exploits Against Software and Defences

1
Exploits Against Software and Defences

• Nicolas T. Courtois -
  University College London

2
How to Break Into Computers?

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

3
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.

4
Goals of Attackers
5
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.

6
Later

• create a backdoor for later access
• cover your traces
• e.g. disable anti-virus, erase log files, etc
• payload execute extra tasks

7
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
8
Whats Wrong?
9
Software Vulnerabilities

1. Input validation problems
2. Buffer overflow
3. Format string vulnerabilities
4. Integer overflows,
5. CPU bugs
6. Failing to handle errors / exceptions properly
7. etc

10
Vectors of Attack - Inputs
11
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

12
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

13
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!
14
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

15
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)

16
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

17
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

18
Buffer Overflow
19
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 requiressource code formal methods
  maths software solver technology lots of
  experimentation machine learning extensive
  knowledge of whats out there etc.

20
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

21
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).

22
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

23
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 dont have the same type.
• Java and C offer (imperfect) memory safety.
• hard to prove, actually shown not quite true for
  Java

24
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.

25
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

26
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.

27
Buffer Overflow AttackStack Smashing and Code
Injection in C
28
Buffer Overflow in C

• char command256
• 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.

29
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.

30
Process Memory Layout

0x08048000
Text

• Text loaded from exec code and read-only
  datasize fixed at compilation
• Heap runtime allocated objects, large (2 Gb)
• Stack LIFO, holds function arguments and local
  variables, small size (256 K)

Heap
Grows toward high memory
Grows toward low memory
0x40000000
Stack
0xC0000000
31
Calling a Sub-Routine in C

• PUSH PULL
• on every CPU since ever

Stack
Stack
Stack
32
Stack Frames for one C Function f

local variables
saved bottom of stack
built in this order
return address
params of f
Stack
Stack
Stack
33
exploit on f

void f(params) char command256 strcpy(co
mmand,sth)
increasing addresses
local variables
saved bottom of stack
overwrite
return address
size easy to guess
params of f
Stack
34
exploit on f

void f(params) char command256 strcpy(co
mmand,sth)
increasing addresses
local variables
shell code
saved bottom of stack
overwrite
return address
easy to guess
0x80707050
params of f
Stack
35
when f finishes

the frame buffer was de-allocated, data still
there
local variables
shell code
saved bottom of stack
return address
return address
0x80707050
params of f
Stack
36
Is It Easy?

• for strcpy() avoid 0s 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 code
NOP slide
37
Reliability

• up to very high, up to 100
• (there are stable exploits, never ever
  fail and produce consistent results)

38
What Hackers Do?
39
Finding Exploits

• Closed 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

40
Example

• With 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

41
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

42
Can We Fix It?
43
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

44
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?

45
Canaries

• Two 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

46
One Attack Against StackGuard and Canaries

47
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.

48
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

system()
local variables
shell code
saved bottom of stack
return address
0x80707050
command123
Stack
49
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)

ms.dll
local variables
shell code
saved bottom of stack
return address
0x80707050
command123
Stack
50
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()

51
C Tips Replace by

• sprintf(buf, ) snprintf(buf, buflen, ),
• scanf(s, buf) scanf(10s, buf),
• strcpy(buf, input) strncpy(buf, input, 256)
• etc

52
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. _at_ 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..

53
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.

54
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

55
END
56
Heap Overflowconsider as home reading, not
at the exam
57
Process Memory Layout

0x08048000
Text

• Text loaded from exec code and read-only
  datasize fixed at compilation
• Heap runtime allocated objects, large (2 Gb)
• Stack LIFO, holds function arguments and local
  variables, small size (256 K)

Heap
Grows toward high memory
Grows toward low memory
0x40000000
Stack
0xC0000000
58
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.

Text
Heap
can take most of the 2-4 Gbytesspace
Grows toward high memory
Stack
59
Insights

• How 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.

60
Insights

• Heap managers have linked lists with
  forward/backward pointers, sizes, and data
  fields.

61
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 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
62
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
63
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
• hdr?next hdr?next?next
• hdr?next?next?prev hdr?next?prev

shell code
64
Insights

• In 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
hdr?next hdr?next?next
65
Insights

• Suppose I override these links to point
• hdr?next to the return address of the function
  on the stack.
• hdr?next?next 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