• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Overflowing attack potential, scoring defence in-depth
 

Overflowing attack potential, scoring defence in-depth

on

  • 681 views

This presentation relates the Common Criteria attack potential calculation with the defence-in-depth technique used to avoid buffer overflows.

This presentation relates the Common Criteria attack potential calculation with the defence-in-depth technique used to avoid buffer overflows.

Statistics

Views

Total Views
681
Views on SlideShare
679
Embed Views
2

Actions

Likes
1
Downloads
7
Comments
0

1 Embed 2

http://www.linkedin.com 2

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Overflowing attack potential, scoring defence in-depth Overflowing attack potential, scoring defence in-depth Presentation Transcript

    • Overflowing Attack Potential Scoring Defence-in-Depth Defence-in- Javier Tallón Guerri 11ICCC - Turkey
    • 2
    • 3
    • 4
    • 1.Buffer overflows, a bit of background2.Reviewing and bypassing defence-in- depth techniques3.Impact in the CC4.What to do? 5
    • 1.Buffer overflows, a bit of background2.Reviewing and bypassing defence-in- depth techniques3.Impact in the CC4.What to do? 6
    • 1. Buffer overflows, a bit of background You know... The classic stack overflow…. #include <string.h> void foo (char *bar) { char c[12]; strcpy(c, bar); // no bounds checking... } int main (int argc, char **argv) { foo(argv[1]); } 7
    • 1. Buffer overflows, a bit of background 8
    • 1. Buffer overflows, a bit of background 9
    • 1. Buffer overflows, a bit of background 10
    • 1. Buffer overflows, a bit of background There are also heap and integer overflows…. 11
    • 1. Buffer overflows, a bit of background Could lead to arbitrary code execution 12
    • 1. Buffer overflows, a bit of background Those were the old days… Very few problems for the attacker: Null bytes Shellcode size and other constraints Shellcode development 13
    • 1.Buffer overflows, a bit of background2.Reviewing defence-in-depth techniques3.Impact in the CC4.What to do? 14
    • 2. Reviewing defence-in-depth techniquesStack canariesapproach: The compiler place a value before the return address when a function is called and check that the value has not changed when the function finalize. 15
    • 2. Reviewing defence-in-depth techniques Bypassing stack canaries: Implementation can be not correct It can be a statistical problem 16
    • 2. Reviewing defence-in-depth techniques Bypassing stack canaries: Windows: SEH overwriting Protected by SafeSEH and so on… Unix: Other (more complex) techniques… 17
    • 2. Reviewing defence-in-depth techniques Non-eXecutable Stack approach: Code is code and data is data Widely deployed (every computer since 2001 allows this) 18
    • 2. Reviewing defence-in-depth techniques Bypassing Non-eXecutable Stack: Save the payload in the heap Return into libc attacks 19
    • 2. Reviewing defence-in-depth techniques 64bits hardware resolves the problem: In 64 bits computers, arguments are loaded from registers, not from the stack. Return into libc attack is not possible 20
    • 2. Reviewing defence-in-depth techniques 64bits hardware resolves the problem: Borrowed Code Chunks or Return Oriented Programming 21
    • 2. Reviewing defence-in-depth techniques 22
    • 2. Reviewing defence-in-depth techniques ASLR (Address Space Layout Randomization) approach: The code is loaded in different memory regions each time 23
    • 2. Reviewing defence-in-depth techniques Bypassing ASLR: It could be an statistical question 24
    • 2. Reviewing defence-in-depth techniques Bypassing ASLR: Maybe not all the libraries are randomly loaded 25
    • 2. Reviewing defence-in-depth techniques Mixed approach: Standalone use of these techniques is not very useful Technique Technique Better A B results 26
    • 2. Reviewing defence-in-depth techniques Non-eXecutable Stack + ASLR: Make very difficult the return attacks. 27
    • 2. Reviewing defence-in-depth techniques NX Stack ASLR Stack Canaries Each technique makes successful exploitation more difficult 28
    • 2. Reviewing defence-in-depth techniques There are more defence-in-depth techniques Attackers always develop techniques to bypass the new countermeasures 29
    • 2. Reviewing defence-in-depth techniques 30
    • 2. Reviewing defence-in-depth techniques 31
    • 1.Buffer overflows, a bit of background2.Reviewing defence-in-depth techniques3.Impact in the CC4.What to do? 32
    • 3. Impact in the CC Overflow detected! Unique characteristics Unique exploit path Base attack potential 33
    • 3. Impact in the CC Buffer Base Defence in Overflow Attack Depth Detected Potential Modifiers Base Attack Potential Real Attack Potential Defence in Depth Modifiers 34
    • 3. Impact in the CCDefence in depth technique Attack potential factorStack Canaries (Windows) x 1.2Stack Canaries + SafeSEH (Windows) x 1.3Non-eXecutable Stack x 1.35ASLR x 1.50Stack Canaries (Unix) x 1.52NX Stack + ASLR x 1.54NX Stack + ASLR + Stack Canaries (Windows) x 1.62NX Stack + ASLR + Stack Canaries + SafeSEH (Windows) x 1.66NX Stack + ASLR + Stack Canaries (Unix) x 1.68… … 35
    • 1.Buffer overflows, a bit of background2.Reviewing defence-in-depth techniques3.Impact in the CC4.What to do? 36
    • 4. What to do? 37
    • 4. What to do? 38
    • 4. What to do? 39
    • 4. What to do? Whenever it is possible Through compiler Through Operating System 40
    • 4. What to do? 41
    • Thanks for your attention! attention!Javier TallónEpoche & Espri, S.L.Avda. de la Vega, 128108, Alcobendas,Madrid, Spain.eval@epoche.es 42