Overflowing attack potential, scoring defence in-depth

945 views

Published on

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

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
945
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
15
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Overflowing attack potential, scoring defence in-depth

  1. 1. Overflowing Attack Potential Scoring Defence-in-Depth Defence-in- Javier Tallón Guerri 11ICCC - Turkey
  2. 2. 2
  3. 3. 3
  4. 4. 4
  5. 5. 1.Buffer overflows, a bit of background2.Reviewing and bypassing defence-in- depth techniques3.Impact in the CC4.What to do? 5
  6. 6. 1.Buffer overflows, a bit of background2.Reviewing and bypassing defence-in- depth techniques3.Impact in the CC4.What to do? 6
  7. 7. 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
  8. 8. 1. Buffer overflows, a bit of background 8
  9. 9. 1. Buffer overflows, a bit of background 9
  10. 10. 1. Buffer overflows, a bit of background 10
  11. 11. 1. Buffer overflows, a bit of background There are also heap and integer overflows…. 11
  12. 12. 1. Buffer overflows, a bit of background Could lead to arbitrary code execution 12
  13. 13. 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
  14. 14. 1.Buffer overflows, a bit of background2.Reviewing defence-in-depth techniques3.Impact in the CC4.What to do? 14
  15. 15. 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
  16. 16. 2. Reviewing defence-in-depth techniques Bypassing stack canaries: Implementation can be not correct It can be a statistical problem 16
  17. 17. 2. Reviewing defence-in-depth techniques Bypassing stack canaries: Windows: SEH overwriting Protected by SafeSEH and so on… Unix: Other (more complex) techniques… 17
  18. 18. 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
  19. 19. 2. Reviewing defence-in-depth techniques Bypassing Non-eXecutable Stack: Save the payload in the heap Return into libc attacks 19
  20. 20. 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
  21. 21. 2. Reviewing defence-in-depth techniques 64bits hardware resolves the problem: Borrowed Code Chunks or Return Oriented Programming 21
  22. 22. 2. Reviewing defence-in-depth techniques 22
  23. 23. 2. Reviewing defence-in-depth techniques ASLR (Address Space Layout Randomization) approach: The code is loaded in different memory regions each time 23
  24. 24. 2. Reviewing defence-in-depth techniques Bypassing ASLR: It could be an statistical question 24
  25. 25. 2. Reviewing defence-in-depth techniques Bypassing ASLR: Maybe not all the libraries are randomly loaded 25
  26. 26. 2. Reviewing defence-in-depth techniques Mixed approach: Standalone use of these techniques is not very useful Technique Technique Better A B results 26
  27. 27. 2. Reviewing defence-in-depth techniques Non-eXecutable Stack + ASLR: Make very difficult the return attacks. 27
  28. 28. 2. Reviewing defence-in-depth techniques NX Stack ASLR Stack Canaries Each technique makes successful exploitation more difficult 28
  29. 29. 2. Reviewing defence-in-depth techniques There are more defence-in-depth techniques Attackers always develop techniques to bypass the new countermeasures 29
  30. 30. 2. Reviewing defence-in-depth techniques 30
  31. 31. 2. Reviewing defence-in-depth techniques 31
  32. 32. 1.Buffer overflows, a bit of background2.Reviewing defence-in-depth techniques3.Impact in the CC4.What to do? 32
  33. 33. 3. Impact in the CC Overflow detected! Unique characteristics Unique exploit path Base attack potential 33
  34. 34. 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
  35. 35. 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
  36. 36. 1.Buffer overflows, a bit of background2.Reviewing defence-in-depth techniques3.Impact in the CC4.What to do? 36
  37. 37. 4. What to do? 37
  38. 38. 4. What to do? 38
  39. 39. 4. What to do? 39
  40. 40. 4. What to do? Whenever it is possible Through compiler Through Operating System 40
  41. 41. 4. What to do? 41
  42. 42. Thanks for your attention! attention!Javier TallónEpoche & Espri, S.L.Avda. de la Vega, 128108, Alcobendas,Madrid, Spain.eval@epoche.es 42

×