Methodical Protection against Code Injection Attacks

1
Methodical Protection against Code Injection
Attacks

• Yves Younan, Wouter Joosen and Frank Piessens
• DistriNet
• Department of Computer Science
• Katholieke Universiteit Leuven
• Belgium
• Yves.Younan_at_cs.kuleuven.ac.be

2
Overview

• Introduction
• Code Injection Attacks
• Model-based countermeasure design
• Conclusion
• Open questions and opportunities

3
Introduction

• Focus is on C/C applications
• Code injection attacks foreign code injected
  into application
• Standard stack-based buffer overflows are harder
  to exploit
• More advanced techniques are being used
• Current countermeasures often fall short
• A more structured approach is needed

4
Overview

• Introduction
• Code Injection Attacks
• First wave
• Second wave
• Third wave
• Model-based countermeasure design
• Conclusion
• Open questions and opportunities

5
First wave stack-based buffer overflows

• Attacker overflows the bounds of a
  stack-allocated array and overwrites the return
  address
• When the function returns the Injected code is
  executed
• Countermeasure StackGuard (Cowan et al), places
  random 32-bit value before the return address and
  checks it before returning
• Attackers developed indirect pointer overwriting
  (IPO) to bypass the countermeasure

6
Second wave Heap-based attacks

• Dynamically allocated memory
• No return addresses
• IPO or function pointer overwriting
• Overwrite memory management information to
  perform indirect pointer overwrite
• Exploitable with heap-overflow and dangling
  pointer reference
• Some allocators can be misused by overflowing
  just 1 byte

7
Second and Third Wave

• Second wave
• Data/bss overflows
• Third wave
• Integer errors
• Integer signedness errors
• Integer overflows
• Format string vulnerabilities
• Fourth wave?

8
Overview

• Introduction
• Code Injection Attacks
• Model-based countermeasure design
• Machinemodel
• A partial machinemodel of dlmalloc
• Countermeasure based on the machine model
• A countermeasure for dlmalloc
• Metamodel and methodology
• Conclusion
• Open questions and opportunities

9
Model-based countermeasure design

• Most countermeasures use an ad-hoc approach when
  protecting applications
• Attackers are using more advanced techniques to
  bypass them.
• A more methodical approach is needed to combat
  code injection attacks
• Building a model of the execution environment
  allows us to evaluate which memory locations to
  protect.

10
Machinemodel

• Addresses and abstractions of control flow
• Addresses that could lead to IPO
• Contextual information
• What is used when
• What operations are performed

11
Countermeasure based on the machinemodel

• Most architectures separate code from data
• Apply a similar approach to data
• Separate control-flow information from regular
  data
• Requires several far reaching changes to the
  memory of the process
• Design is aided by the machine model

12
Countermeasure based on the machinemodel

• Modify the way the stack is organized 3 stacks
• Control information return address, frame
  pointer, pointers and arrays of pointers (bounds
  checked)
• Integers and floating types
• Regular arrays
• Modify malloc management information
• Information is stored out-band (at the end of the
  heap)

13
Countermeasure based on the machinemodel

• Reorganize the data segment
• The memory in the data segment must be organized
  in a different order.

14
A modified machinemodel for dlmalloc
15
A modified machinemodel for dlmalloc
16
Modified dlmalloc
Spec CPU2000 results for dlmalloc and dnmalloc
(13 runs on 8 identical pcs (P4 2.8ghz, 512mb)
104 runs)
17
Overview

• Introduction
• Attacks
• Model-based countermeasure design
• Metamodel and methodology
• Conclusion
• Open questions and opportunities

18
Metamodel and methodology

• A machine model is strongly linked to an
  architecture
• -gt limited usefulness.
• Metamodel is an abstraction of several machine
  models.
• Allows reasoning about countermeasures at a very
  high level of abstraction.
• Platform expert metamodel methodology -gt build
  a machinemodel
• Security expert design countermeasure on
  machinemodel

19
Overview

• Introduction
• Attacks
• Model-based countermeasure design
• Metamodel and methodology
• Conclusion
• Open questions and opportunities

20
Conclusion

• Many countermeasures can be bypassed using
• one of the techniques described earlier.
• A more structured approach is needed at a higher
  level of abstraction
• By using machine models and a metamodel
• Supports collaboration
• Less prone to porting errors
• Better design
• Platform for comparing and evaluating
  countermeasures
• More information http//fort-knox.org

21
Overview

• Introduction
• Attacks
• Model-based countermeasure design
• Metamodel and methodology
• Conclusion
• Open questions and opportunities

22
Open questions and opportunities

• Modeling representation UML is inadequate
• Build model/metamodel for embedded systems
• Should short-term focus lie on building
  countermeasures or on constructing the
  methodology
• Build more machinemodels first or implement more
  countermeasures first
• Use the model for automatic reasoning on
  countermeasure security (prove some aspects)

23
(No Transcript)
24
First wave Stack-based buffer overflows
Stack
High addr
f0
Return address f0

Saved Frame Ptr f0
Stack frame f0
call f1
Local variables f0

Arguments f1
f1
buffer
Return address f1
overflow()

Stack frame f1
Saved Frame Ptr f1
Buffer
Injected code
25
First wave Countermeasure StackGuard
Stack
High addr
f0
Return address f0

Saved Frame Ptr f0
Stack frame f0
call f1
Canary

Local variables f0
f1
Arguments f1
buffer
overflow()
Return address f1

Stack frame f1
Saved Frame Ptr f1
Canary
Injected code
Buffer
26
Second wave Indirect Pointer Overwriting
Stack
High addr
f0
Return address f0

Saved Frame Ptr f0
Stack frame f0
call f1
Canary

Local variables f0
f1
Arguments f1
pointer
buffer
Return address f1
overflow()
Stack frame f1
Saved Frame Ptr f1
pointer
Canary
Data
Pointer
Value1
Value2
Injected code
Buffer
27
Second wave Countermeasure Propolice
Stack
High addr
f0
Return address f0

Saved Frame Ptr f0
Stack frame f0
call f1
Canary

Local variables f0
f1
Arguments f1
pointer
buffer
Return address f1
overflow()
Stack frame f1
Saved Frame Ptr f1
pointer
Canary
Data
Value1
Injected code
Value2
Buffer
Pointer
28
Second WaveData/bss overflows

• Data contains global or static compile-time
  initialized data
• Bss contains global or static uninitialized data
• Stored together with other sections that control
  program execution
• An attacker can overflow into other sections

.data
.eh_frame
.ctors
.dtors
.got
.bss
.dtors
function pointer
function pointer
29
Heap-vulnerabilities

• Heap overflows and double frees exist for many
  memory allocators
• Dlmalloc (overflow, double free)
• CSRI (overflow)
• Quickfit (overflow)
• Phkmalloc (overflow)
• Boehms Garbage Collector (overflow, double free)

30
Doug Leas malloc
Chunk3
Chunk1
Size of prev chunk
Size of chunk1
User data
Chunk4
Chunk2
High addr
31
Heap-based buffer overflows
Chunk3
Chunk1
Size of prev chunk
Size of chunk1
User data
Injected code
Chunk4
Chunk2
Size of chunk1
Size of chunk2
Forward Pointer
Backward Pointer
Old user data
Stack
Return address
32
Second wave Dangling pointer references
Chunk3
Chunk2
Chunk1
Size of prev chunk
Size of prev chunk
Size of prev chunk
Size of chunk
Size of chunk
Size of chunk
Forward Pointer
Forward Pointer
Forward Pointer
Backward Pointer
Backward Pointer
Backward Pointer
User data
Old user data
Old user data
Old user data
Injected Code
Stack
Return address
33
A partial machinemodel of dlmalloc