[PPT] - String Oriented Programming: When ASLR is not enough Mathias Payer* PowerPoint Presentation

SLIDE 1

String Oriented Programming: When ASLR is not enough

Mathias Payer* and Thomas R. Gross Department of Computer Science ETH Zürich, Switzerland

* now at UC Berkeley

SLIDE 2

2

Current protection is not complete

http://creoflick.net

SLIDE 3

3

Motivation: circumvent protections

Format string exploits are often overlooked

Drawback: hard to construct (due to protection mechanisms)
Define a way to deterministically exploit format string bugs

1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 100 200 300 400 500 600 700 800 900 1000

Common Vulnerabilities and Exposures

Buffer {over|under}flow Use-after-free Format string Year Number of vulnerabilities

SLIDE 4

5

Attack model

Attacker with restricted privileges forces escalation Attacker knows both source code and binary Definition of a successful attack

Redirect control flow to alternate location
Injected code is executed or alternate data is used for existing code

SLIDE 5

6

Outline

Motivation Attack model Current protection and their weaknesses Attack building blocks String Oriented Programming Conclusion

SLIDE 6

7

Current protection

SLIDE 7

8

Current protection

Data Execution Prevention

http://www.computing.co.uk

Address Space Layout Randomization

Ted Atchley, http://torwars.com

Canaries

http://socialcanary.com

SLIDE 8

9

Data Execution Prevention (DEP)

DEP protects from code-injection attacks

Based on page table modifications
A memory page is either executable or writable (not both)

Weaknesses and limitations:

No protection against code-reuse attacks like return-oriented

programming or jump-oriented programming

Self-modifying code not supported

SLIDE 9

10

Addr. Space Layout Rand. (ASLR)

ASLR randomizes code and data layout

Probabilistic protection against attacks based on the loader
Locations of all non-static memory regions are randomized during

startup

Weaknesses and limitations

Some regions remain static for every run
Prone to information leaks: randomization remains static during

execution

Performance impact on randomized code (~10%)

SLIDE 10

11

ASLR Performance Overhead

ASLR uses one register for PIC / ASLR code

On IA32 this leads to a performance degradation

458.sjeng 400.perlbench 453.povray 401.bzip2 482.sphinx3 445.gobmk 462.libquantum 464.h264ref 403.gcc 471.omnetpp 483.xalancbmk 456.hmmer 450.soplex 473.astar 429.mcf 433.milc 447.dealII 444.namd 470.lbm Average

Geo. Mean

0.00% 5.00% 10.00% 15.00% 20.00% 25.00% 30.00%

Overhead for -fPIE

O3 -fPIE
O2 -fPIE

SPEC CPU2006 benchmark Overhead

SLIDE 11

12

Canaries

Canaries protect against buffer overflows

Compiler modifies stack and structure layout
Canaries are placed between buffers and other variables, content is

verified after buffer operations

Weaknesses and limitations

Only protect against continuous writes (buffer overflows)
No protection against targeted writes (or reads)
Prone to information leaks: usually one canary value per execution

SLIDE 12

13

Defense summary

Both Canaries and ASLR are probabilistic and prone to information leaks

One shot attack becomes two shot attack
Performance issues or data-layout issues

DEP gives us code integrity

Protects against code injection, not code-reuse
Code-reuse attacks needed to exploit DEP
Hardware extension

SLIDE 13

14

Outline

Motivation Attack model Current protection and their weaknesses Attack building blocks String Oriented Programming Mitigation Conclusion

SLIDE 14

15

printf functionality

Format string contains tokens

Each token consumes a stack slot and prints it
Format dependent on token

printf("fooo") "fooo" printf("%s", "bar") "bar" printf("%d", 0x24) "36" printf("%2s", "foo", "bar") "bar" printf("%3c", 'A', 'B', 'C') "C" printf("%$2c", 'A' ) " A" printf("%2$3c", 'A', 'B') " B" printf("foo%n", &counter) "foo"

SLIDE 15

16

Format string attack*

Attacker controlled format results in arbitrary writes

Format strings consume parameters on the stack
%

n token inverses order of input, results in indirect memory write

Often string is on stack and can be used to store pointers

Write 0 x c f 3 b a b e to 0 x 4 1 4 1 4 1 4 1 :

p

r i n t f ( " A A A A C A A A % 1 $ 4 9 3 8 7 c % 6 $ h n % 1 $ 6 3 9 4 7 c % 5 $ h n " ) ;

Random writes are used to:

Redirect control flow
Prepare/inject malicious data

p r i n t f ( "AAAACAAA" /* encode 2 halfword pointers / "%1$49387c" / write 0xc0f3 – 8 bytes / "%6$hn" / store at second HW / "%1$63947c%5$hn" / repeat with 0xbabe */ );

* many references, e.g., Haas, Defcon 18

SLIDE 16

17

Return Oriented Programming (ROP)*

ROP based on stack invocation frames

Executes arbitrary code
Initial bug prepares stack invocation frames

return address (data) return address (data) (don't care) (don't care)

0xffe0

return address (data)

0xffff

insns … … ret insns … … ret insns … … ret insns … … ret Gadget catalog (at static addrs)

length of user input

* Shacham, CCS'07

SLIDE 17

18

Outline

Motivation Attack model Current protection and their weaknesses Format String Exploits String Oriented Programming

Technique
Example

Mitigation Conclusion

SLIDE 18

19

String Oriented Programming (SOP)

Observation: format string attacks inject data into running applications Executing arbitrary code (through data)

Needed: format string bug, attacker-controlled buffer on stack
Not needed: buffer overflow, executable writable memory regions

SOP builds on ROP/JOP

Overwrites static instruction pointers

SLIDE 19

20

String Oriented Programming (SOP)

Patching and resolving addresses

Application is static (this includes application's .plt and .got)
Static program locations used to resolve relative addresses

Resolving hidden functions

ASLR randomizes ~10bit for libraries
Modify parts of static .got pointers
Hidden functions can be called without loader support

SLIDE 20

21

Running example

void foo(char *arg) { char t e x t [ 1 2 4 ] ; // buffer on stack if (s t r l e n ( a r g ) > = 1 2 4 ) // length check return; strcpy(text, arg); p r i n t f ( t e x t ) ; // vulnerable printf } … foo(u s e r _ s t r ); // unchecked user data …

SLIDE 21

22

text[1024]

SOP: No Protection

All addresses are known, no execution protection, no stack protection

Redirects control flow to code in the format string itself

&arg … ? ... 0xFFF0 eip to caller saved ebp ... 12b unused ... random write & exploit code copy of &arg ptr to 0xFBD4 RIP to foo saved ebp (0xFFE4) 0xFFD4 0xFBD4 printf data RIP to 0xFBD4

void f

(char *arg) {

char t e x t [ 1 2 4 ] ; if (s t r l e n ( a r g ) > = 1 2 4 ) return; strcpy(text, arg); p r i n t f ( t e x t ) ; } … foo(u s e r _ s t r ); …

SLIDE 22

23

SOP: Only DEP

DEP prevents code injection, rely on ROP/JOP instead GNU C compiler adds frame_lift gadget

&arg … ? ... 0xFFF0 eip to caller saved ebp ... 12b unused ... copy of &arg ptr to 0xFBD4 RIP to foo saved ebp (0xFFE4) 0xFFD4 0xFBD4 printf data

add $0x1c,%esp pop %ebx pop %esi pop %edi pop %ebp ret

RIP to frame_lift text[1024] random write & stack invocation frames 0xFFD4 0xFBD4

void f

(char *arg) {

char t e x t [ 1 2 4 ] ; if (s t r l e n ( a r g ) > = 1 2 4 ) return; strcpy(text, arg); p r i n t f ( t e x t ) ; } … foo(u s e r _ s t r ); …

SLIDE 23

24

SOP: DEP & Canaries

ProPolice uses/enforces stack canaries

Reuse attack mechanism, keep canaries intact

12b unused &arg … ? ... 0xFFF0 eip to caller saved ebp 8b unused text[1024] copy of canary &arg ptr to 0xFBD8 RIP to foo saved ebp (0xFFE4) random write & stack invocation frames 0xFFD8 0xFBD8 printf data 16b unused copy of canary &arg stack canary

add $0x1c,%esp pop %ebx pop %esi pop %edi pop %ebp ret

RIP to frame_lift

void f

(char *arg) {

char t e x t [ 1 2 4 ] ; if (s t r l e n ( a r g ) > = 1 2 4 ) return; strcpy(text, arg); p r i n t f ( t e x t ) ; } … foo(u s e r _ s t r ); …

SLIDE 24

25

SOP: ASLR, DEP, Canaries

Combined defenses force SOP to reuse existing code

Static code sequences in the application object
Imported functions in the application (.plt and .got)

Use random byte-writes to adjust .got entries

Enable other functions / gadgets that are not imported
Combine stack invocation frames and indirect jump/call gadgets

void foo(char *prn) { char t e x t [ 1 ] ; // protected on stack strcpy(text, prn); p r i n t f ( t e x t ) ; // vulnerable printf p u t s ("logged in\n"); // 'some' function }

SLIDE 25

26

SOP: ASLR, DEP, Canaries

.init .plt .text .fini .got: … .got.plt:

system

Application (static) Libraries, heap, stack(s) (dynamic) libc (text, data, got)

RX RW

printf __stack_chk_fail puts system@plt puts@plt lift_esp_gadget

12b unused &arg … ? ... 0xFFF0 eip to caller saved ebp 8b unused string array copy of canary &arg ptr to 0xFBD8 RIP to foo saved ebp (0xFFE4) printf data 16b unused copy of canary &arg stack canary

heap

0xFFD8 0xFBD8

void foo(char *prn) { char t e x t [ 1 ] ; strcpy(text, prn); p r i n t f ( t e x t ) ; p u t s ("logged in\n"); }

SLIDE 26

27

SOP: ASLR, DEP, Canaries

.init .plt .text .fini .got: … .got.plt:

system

Application (static) Libraries, heap, stack(s) (dynamic) libc (text, data, got)

RX RW

printf __stack_chk_fail puts system@plt puts@plt lift_esp_gadget

12b unused &arg … ? ... 0xFFF0 eip to caller saved ebp 8b unused string array copy of canary &arg ptr to 0xFBD8 RIP to foo saved ebp (0xFFE4) printf data 16b unused copy of canary &arg stack canary 3 random writes & stack invocation frames

heap

puts "/bin/sh\0"

0xFFD8 0xFBD8

void foo(char *prn) { char t e x t [ 1 ] ; strcpy(text, prn); p r i n t f ( t e x t ) ; p u t s ("logged in\n"); }

SLIDE 27

28

Outline

Motivation Attack model Current protection and their weaknesses Format String Exploits String Oriented Programming Mitigation Conclusion

SLIDE 28

29

Mitigation

Control-flow protection

Use a shadow stack to protect the RIP
Protect indirect control flow transfers

Disable writes in format strings

Remove %

n processing

Add (static and dynamic) compiler checks for valid targets

SLIDE 29

30

Outline

Motivation Attack model Current protection and their weaknesses Format String Exploits String Oriented Programming Mitigation Conclusion

SLIDE 30

31

Conclusion

String Oriented Programming (SOP)

Based on format string exploit
Extends code-reuse attacks (ROP / JOP)
Naturally circumvents DEP and Canaries
Reconstructs pointers and circumvents ASLR

Format string bugs result in complete compromise of the application and full control for the attacker

SOP protection needs more work (virtualization, or secure libc?)
Look at the complete toolchain

SLIDE 31

32

Questions?

?

SLIDE 32

33

Other protection mechanisms

Stack integrity (StackGuard, Propolice) Verify library usage (Libsafe / Libverify) Pointer encryption (PointGuard) ISA modifications (ISA randomization) Format string protection (FormatGuard) Randomize memory locations (ASLR) Check/verify control flow transfer (CFI / XFI)

SLIDE 33

34

Software based fault isolation

Translates individual basic blocks
Checks branch targets and origins
Weaves guards into translated code

1 1' 2 2' 3 3' … ... Original code Code cache Mapping table Dynamic translator 1 2 4 3 1' 2' 3' R RX

Indirect control flow transfers use a dynamic check to verify target and

rigin

String Oriented Programming: When ASLR is not enough

Mathias Payer* and Thomas R. Gross Department of Computer Science ETH Zürich, Switzerland

* now at UC Berkeley

Current protection is not complete

Motivation: circumvent protections

Format string exploits are often overlooked

Common Vulnerabilities and Exposures

Attack model

Attacker with restricted privileges forces escalation Attacker knows both source code and binary Definition of a successful attack

Outline

Motivation Attack model Current protection and their weaknesses Attack building blocks String Oriented Programming Conclusion

Current protection

Current protection

Data Execution Prevention

Address Space Layout Randomization

Canaries

Data Execution Prevention (DEP)

DEP protects from code-injection attacks

Weaknesses and limitations:

programming or jump-oriented programming

ASLR randomizes code and data layout

startup

Weaknesses and limitations

execution

ASLR Performance Overhead

ASLR uses one register for PIC / ASLR code

Overhead for -fPIE

Canaries

Canaries protect against buffer overflows

verified after buffer operations

Weaknesses and limitations

Defense summary

Both Canaries and ASLR are probabilistic and prone to information leaks

DEP gives us code integrity

Outline

Motivation Attack model Current protection and their weaknesses Attack building blocks String Oriented Programming Mitigation Conclusion

printf functionality

Format string contains tokens

printf("fooo") "fooo" printf("%s", "bar") "bar" printf("%d", 0x24) "36" printf("%2s", "foo", "bar") "bar" printf("%3c", 'A', 'B', 'C') "C" printf("%$2c", 'A' ) " A" printf("%2$3c", 'A', 'B') " B" printf("foo%n", &counter) "foo"

Format string attack*

Attacker controlled format results in arbitrary writes

n token inverses order of input, results in indirect memory write

Write 0 x c f 3 b a b e to 0 x 4 1 4 1 4 1 4 1 :

r i n t f ( " A A A A C A A A % 1 $ 4 9 3 8 7 c % 6 $ h n % 1 $ 6 3 9 4 7 c % 5 $ h n " ) ;

Random writes are used to:

p r i n t f ( "AAAACAAA" /* encode 2 halfword pointers */ "%1$49387c" /* write 0xc0f3 – 8 bytes */ "%6$hn" /* store at second HW */ "%1$63947c%5$hn" /* repeat with 0xbabe */ );

Return Oriented Programming (ROP)*

ROP based on stack invocation frames

Outline

Motivation Attack model Current protection and their weaknesses Format String Exploits String Oriented Programming

Mitigation Conclusion

String Oriented Programming (SOP)

Observation: format string attacks inject data into running applications Executing arbitrary code (through data)

SOP builds on ROP/JOP

String Oriented Programming (SOP)

Patching and resolving addresses

Resolving hidden functions

Running example

void foo(char *arg) { char t e x t [ 1 2 4 ] ; // buffer on stack if (s t r l e n ( a r g ) > = 1 2 4 ) // length check return; strcpy(text, arg); p r i n t f ( t e x t ) ; // vulnerable printf } … foo(u s e r _ s t r ); // unchecked user data …

SOP: No Protection

All addresses are known, no execution protection, no stack protection

void f

char t e x t [ 1 2 4 ] ; if (s t r l e n ( a r g ) > = 1 2 4 ) return; strcpy(text, arg); p r i n t f ( t e x t ) ; } … foo(u s e r _ s t r ); …

SOP: Only DEP

DEP prevents code injection, rely on ROP/JOP instead GNU C compiler adds frame_lift gadget

void f

char t e x t [ 1 2 4 ] ; if (s t r l e n ( a r g ) > = 1 2 4 ) return; strcpy(text, arg); p r i n t f ( t e x t ) ; } … foo(u s e r _ s t r ); …

SOP: DEP & Canaries

ProPolice uses/enforces stack canaries

void f

char t e x t [ 1 2 4 ] ; if (s t r l e n ( a r g ) > = 1 2 4 ) return; strcpy(text, arg); p r i n t f ( t e x t ) ; } … foo(u s e r _ s t r ); …

SOP: ASLR, DEP, Canaries

Combined defenses force SOP to reuse existing code

Use random byte-writes to adjust .got entries

void foo(char *prn) { char t e x t [ 1 ] ; // protected on stack strcpy(text, prn); p r i n t f ( t e x t ) ; // vulnerable printf p u t s ("logged in\n"); // 'some' function }

SOP: ASLR, DEP, Canaries

void foo(char *prn) { char t e x t [ 1 ] ; strcpy(text, prn); p r i n t f ( t e x t ) ; p u t s ("logged in\n"); }

SOP: ASLR, DEP, Canaries

void foo(char *prn) { char t e x t [ 1 ] ; strcpy(text, prn); p r i n t f ( t e x t ) ; p u t s ("logged in\n"); }

Outline

p r i n t f ( "AAAACAAA" /* encode 2 halfword pointers / "%1$49387c" / write 0xc0f3 – 8 bytes / "%6$hn" / store at second HW / "%1$63947c%5$hn" / repeat with 0xbabe */ );