AllBits presentation - Lower Level SW Security

29-01-2015 by Bart Van Bos - AllBits29-01-2015 by Bart Van Bos - AllBits
Low Level Software SecurityLow Level Software Security
The never ending arms race

Presentation Overview
● Introduction
– Buffer overflows
– Memory management
– Process memory layout
– Function call stack frames
● Example attacks
● Defenses
● Conclusion

Vulnerability Landscape
https://courses.cs.washington.edu/courses/cse484/14au/reading/25-years-vulnerabilities.pdf

Popular Vulnerabilities
At The Vulnerability Oscars
– NIST Common Vulnerabilities and Exposures DB (CVE)
– Common Vulnerability Scoring System (CVSS) data from 1988 to
2012 (53.221 vulnerabilities)
– Famous examples (all stack-based buffer overflows)
● Sasser worm: shut down X-ray machines at a Swedish hospital and caused
Delta airlines to cancel several transatlantic flights
●
Heartbleed: in the OpenSSL cryptography library, which is a widely used
implementation of the Transport Layer Security (TLS) protocol.
●
Stuxnet: targeted Iran’s nuclear program and is believed to have caused it
delays/damage
Vulnerability All High Critical
Buffer Overflow 7809 5528 1391
Cross-Site scripting (XSS) 7006 141 0

Hot off the press
● [27-01-2015] GHOST – glibc gethostbyname buffer overflow
(CVE-2015-0235)
– During a code audit, a buffer overflow in the __nss_hostname_digits_dots() function of the
GNU C Library (glibc) was discovered. This bug is reachable both locally and
remotely via the gethostbyname*() functions. They named this vulnerability
GHOST
– Arbitrary code execution can be achieved. As a proof of concept, a full-fledged
remote exploit against the Exim mail server, bypassing all existing protections
(ASLR, PIE, and NX) on both 32-bit and 64-bit machines, is developed. The
exploit will be published as a Metasploit module in the near future.
– Vulnerability glibc <= 2.17
● Debian 6-LTS and Debian 7
● Ubuntu <= 13.10
● RedHat Enterprise Linux 5, 6 and 7
● CentOS 5, 6 and 7
http://www.openwall.com/lists/oss-security/2015/01/27/9

Memory corruption vulnerability
● Memory corruption vulnerabilities are a class of
vulnerabilities for unsafe languages, like C, C++
and Objective C
– Languages tat do not check whether programs access memory
in a correct way
– Hence bugs might get introduce that mess up part of memory at
run-time
● In this presentation, the focus is on memory
corruption in C programs.
– An attacker will be allowed to do anything he wants on
the machine...

Memory management in C
● Memory can be allocated in many ways
– Automatic (local variables in functions)
– Static (global variables)
– Dynamic (malloc and new)
● Programmer is responsible for
– Appropriate use of allocated memory:
● bounds checks, type checks, ...
– Correct allocation and de-allocation in the case
of dynamic memory (free)

Process memory layout
Program Code
RO [.init .text .rodata]
Static & Global Data
R/W [.data .bss]
Run-time HEAP
(created runtime - malloc)
Unused and memory mapped
region for shared libs
User STACK
(created at runtime)
Program args + ENV vars
High Addresses
Low Addresses
Stack grows
down
Heap grows
up
Grows &
shrinks
dynamically

Common memory bugs in C
● Memory management is very error prone
● Typical bugs
– Buffer overflow: writing past the bounds of an array
– Dangling pointers: pointers to deallocated memory
– Double frees: deallocating memory twice
– Memory leaks: never deallocating memory
● For efficiency reasons, C-like compilers don’t
detect these bugs at run-time
– C standard states behavior of such programs is undefined

Function call & stack frame
● Per call, an activation record or stack frame
is pushed on the stack, containing
– Actual parameters, return address, automatically
allocated local variables, …
– RBP and RSP (x86-64)
● register base pointer (ebp)
● register stack pointer (esp)
long my_function(long a, long b, long c, long d,
long e, long f, long g, long h) {
long xx = a * b * c * d * e * f * g * h;
long yy = a + b + c + d + e + f + g + h;
long zz = util_function(xx, yy, xx % yy);
return zz + 20;
}
h
g
return address
saved RBP
xx
yy
zz
…
...
high address
low address
RBP
RBP-8
RBP-16
RBP-24
RBP+8
RBP+16
RBP+24
“red zone”
128 bytes
a
b
c
d
f
e
RDI
RSI
RDX
RCX
R8
R9
x86-64
registers
RSP
RBP
http://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64

Processor endianness
● Endianness refers to the convention used to interpret the bytes
making up a data word when those bytes are stored in computer
memory. When reading or writing a data word consisting of
multiple bytes, the order of the bytes stored in memory determines
the interpretation of the data word
– Intel processors are little-endian (i386 i486 i586 i686 x86-64)
LITTLE ENDIAN
x41 x42 x43 x44
x44
x43
x42
x41
...
...
memory
register
a
a+1
a+2
a+3
x41 x42 x43 x44
register
x41
x42
x43
x44
...
...
memory
a
a+1
a+2
a+3
BIG ENDIAN

● Introduction
● Example attacks
– Data-only attacks (by example)
– Stack-based buffer overflow (by example)
– Indirect pointer overwriting
– Heap-based buffer overflow
– Return-to-libc attacks
● Defenses
● Conclusion

Data only attack
● Change the outcome of a program by overwriting a
variable you are not supposed to be able to access
● Make the following program print
“you win!”
return address
saved RIP
x6Cx6Bx6Ax69
x64x63x62x61 x68x67x66x65
x70x6Fx6Ex6D
xF7xA3x5ExC5 x00x00x7FxFF
x00x00x00x00 x00x00x00x00
LOW
HIGH

Stack based overflow
● Overflow a variable in order to change the return address (RIP)
and redirect it to injected shellcode
– Shellcode is assembly code which performs some kind of attack
– Shellcode can be easily generated using Metasploit framework
– Should not contain 0x00, since this stops exploit execution
– Often contains a NOP slide (0x90)
when address uncertain
[SECTION .text]
global _start
_start:
int 0x80 ; OS syscall (SW interrupt)
L: jmp L ; very short, direct infinite loop
00000000 CD 80 int 0x80
00000002 EB FE jmp short 0x2
unsigned char shellcode[] = {
0xcd, 0x80, 0xeb, 0xfe
};

F0:
…
call F1
...
F1:
buffer[]
overflow()
...
other stack frames
return address F0
saved frame pointer F0
local variables F0
arguments F1
IP
FP
SP
Stack

F0:
…
call F1
...
F1:
buffer[]
overflow()
...
other stack frames
return address F0
local variables F0
arguments F1
IP FP
SP
local variables F0
arguments F1
return address F1
buffer
Stack

Stack
F0:
…
call F1
...
F1:
buffer[]
overflow()
...
other stack frames
return address F0
local variables F0
arguments F1
IP
FP
SP
local variables F0
arguments F1
overwrite return address
injected shellcode

F0:
…
call F1
...
F1:
buffer[]
overflow()
...
other stack frames
return address F0
local variables F0
arguments F1
IP
SP
local variables F0
injected shellcode
Stack

Indirect Pointer Overwriting
● Overwrite a target memory location by overwriting a data
pointer
– An attackers makes the data pointer point to the target
location
– When the pointer is dereferenced for writing, the target
location is overwritten
– If the attacker can specify the value of to write, he can
overwrite arbitrary memory locations with arbitrary
values

Indirect pointer overwriting
F0:
…
call F1
...
F1:
ptr = &data
buffer[]
overflow()
*ptr = value
...
other stack frames
return address F0
local variables F0
arguments F1
IP
FP
SP
local variables F0
arguments F1
return address F1
data pointer
Stack
data
buffer

● Make the data pointer refer to the
address where the return address is
stored
F0:
…
call F1
...
F1:
ptr = &data
buffer[]
overflow()
*ptr = value
...
other stack frames
return address F0
local variables F0
arguments F1
IP
FP
SP
local variables F0
arguments F1
return address F1
overwrite data pointer
Stack
data
injected shell code

● Change the memory at the
address in ptr to be value
F0:
…
call F1
...
F1:
ptr = &data
buffer[]
overflow()
*ptr = value
...
other stack frames
return address F0
local variables F0
arguments F1
IP
FP
SP
local variables F0
arguments F1
modified return address
overwrite data pointer
Stack
data
injected shell code

F0:
…
call F1
...
F1:
ptr = &data
buffer[]
overflow()
*ptr = value
...
other stack frames
return address F0
local variables F0
IP
FP
SP
local variables F0
Stack
data
injected shell code

● Introduction
● Example attacks
● Defenses
– Stack canaries
– None executable data
– Layout randomization (ASLR)
– Fortify source macro
● Conclusion

Stack canaries
● Basic idea
– Insert a random number right in a stack frame right before the
stored base pointer/return address
– Verify on return from a function that this value was not modified
– If changed, an overflow has occurred, terminate the program
● The inserted value is called a canary, after the
coal mine canaries
CFLAGS: -fstack-protector
NOTE: In Ubuntu 6.10 and later versions this option is enabled by
default for C, C++, ObjC, ObjC++, if -fno-stack-protector is not
found.

F0:
…
call F1
...
F1:
buffer[]
overflow()
...
other stack frames
return address F0
local variables F0
arguments F1
IP FP
SP
canary
arguments F1
return address F1
canary
Stack
buffer

F0:
…
call F1
...
F1:
buffer[]
overflow()
...
other stack frames
return address F0
local variables F0
arguments F1
IP
FP
SP
canary
arguments F1
overwrite return address
canary
Stack

None executable data
● Direct code injection attacks at some point execute data,
since most programs never need to do this
● Hence, a simple countermeasure is to mark data memory
(stack, heap, ...) as non-executable
● This counters direct code injection, but not return-into-libc
or data-only attacks
● In addition, this countermeasure may break certain legacy
applications
LDFLAGS = -z noexecstack
# execstack --set-execstack <program>
tool to set, clear, or query executable stack flag
of ELF binaries and shared libraries

Layout randomization
● Most attacks rely on precise knowledge of run time
memory addresses
● Introducing artificial variation in these addresses
significantly raises the bar for attackers
● Such address space layout randomization (ASLR) is
a cheap and effective countermeasure
● Managed by the Linux Kernel
# echo /proc/sys/kernel/randomize_va_space
2 Randomize the positions of the stack, VDSO page,
shared memory regions, and the data segment. This
is the default setting.

Defense effectiveness
Data only Stack return
address
Heap function*
corruption
Jump to libc
Stack Canary
(D1)
Partial
defense
Partial
defense
Partial
defense
NX Data
(D2)
Partial
defense
Partial
defense
Partial
defense
ASLR
(D3)
Partial
defense
Partial
defense
Partial
defense
Partial
defense
➢ There is no on defense that covers all attacks 100%
➢ More protection at the source level (compile-time)

Fortify source macro
● Lightweight checks to detect buffer overflow at
both compile and run time
● Functions covered
– memcpy, mempcpy, memmove, memset, stpcpy, strcpy,
strncpy, strcat, strncat, sprintf, snprintf, vsprintf, vsnprintf,
and gets.
● Since glibc 2.3.4 & gcc v4.0
CFLAGS = -D_FORTIFY_SOURCE=2
In Ubuntu 8.10 and later versions, -D_FORTIFY_SOURCE=2
is set by default. This enables additional compile-time and
run-time checks for several libc functions.

● Introduction
● Example attacks
● Defenses
● Conclusion

Conclusion
● The design of attacks and countermeasures has led
to an arms race between attackers and defenders
● While significant hardening of the execution of C-like
languages is possible, the use of safe languages like
Java / C# is from the point of view of security
preferable
● Testing tools: blind/directed fuzzing
● Analysis tools
● Code review

References
● Smashing the Stack for Fun and Profit (Aleph One)
– http://insecure.org/stf/smashstack.html
● Low level Software Security by Example
(Erlingsson, Younan & Piessens)
– https://courses.cs.washington.edu/courses/cse484/14au/reading/
low-level-security-by-example.pdf
● Insecure Programming by example
– http://community.coresecurity.com/~gera/InsecureProgramming
● Code samples available on GitHub
– https://github.com/boeboe/low-level-security

Q&A
● Thanks for your attention
Email: bartvanbos@allbits.eu
LinkedIn: http://lnkd.in/Kre-kR

AllBits presentation - Lower Level SW Security

More Related Content

AllBits presentation - Lower Level SW Security

Editor's Notes