Effective Countermeasures Against Cyber Attacks

 
Part III
Counter measures
 
The best defense is proper bounds checking
but there are many C/C++ programmers
and some are bound to forget
 
 
 Are there any 
system 
defenses that can help?
 
HOW DO WE STOP THE ATTACKS?
 
HOW DO WE STOP THE ATTACKS?
 
A variety of tricks in combination
        NX bit                 Canaries                  ASLR
 
fin
 
III.A
Canaries
 
Goal: make sure we detect overflow of return address
The functions' prologues insert a 
canary
 on the stack
The canary is a 32-bit value inserted between the return
address and local variables
Types of canaries:
1.
Terminator
2.
Random
3.
Random XOR
The epilogue checks if the canary has been altered
Drawback: requires recompilation
 
Compiler-level techniques
Canaries
 
Canaries
 
How good are they?
 
Assume random canaries protect the stack
 
Can you still exploit this?
 
Another example
 
III.B
“DEP”
 
DEP / NX bit / W
X
 
Idea: separate executable memory locations
from writable ones
A memory page cannot be both writable and
executable at the same time
“Data Execution Prevention (DEP)”
 
Bypassing W
X
 
Return into libc
Three assumptions:
We can manipulate a code pointer
The stack is writable
We know the address of a “suitable" library
function (e.g., 
system()
)
Stack
 
Why the 
“ret address”
?
What could we do with it?
0x08048430
 
 
 
 
 
 
buf
0xbfffeedc
0xbfffeeb0
0xbfffeeb4
0xbfffeeb8
0xbfffeebc
0xbfffeec0
0xbfffeec4
0xbfffeec8
0xbfffeecc
0xbfffeed0
0xbfffeed4
0xbfffeed8
0xbfffeea4
0xbfffeea8
0xbfffeeac
“ret address”
arg
arg
0xbfffeee8
0xbfffeee0
0xbfffeee4
 
Return Oriented Programming
 
ROP chains:
Small snippets of code ending with a RET
Can be chained together
 
 
Return Oriented Programming
 
ROP chains
Small snippets of code ending with a RET
Can be chained together
 
&gadget1
&gadget2
&gadget3
--
ret
ret
 
stack
 
How good are they?
 
Assume random canaries protect the stack
Assume DEP prevents execution of the stack
 
III.C
ASLR
 
Let us make it a little harder still…
 
Address Space Layout Randomisation
 
Idea:
Re-arrange the position of key data areas
randomly (stack, .data, .text, shared libraries, . . . )
Buffer overflow: the attacker does not know the
address of the shellcode
Return-into-libc: the attacker can't predict the
address of the library function
Implementations: Linux kernel > 2.6.11, Windows
Vista, . . .
 
ASLR: Problems
 
32-bit implementations use few randomisation bits
An attacker can still exploit non-randomised areas, or
rely on other information leaks (e.g., format bug)
 
 
 
So… (I bet you saw this one coming)….
 
How good are they?
 
Assume random canaries protect the stack
Assume DEP prevents execution of the stack
Assume ASLR randomized the stack 
and
 the
start address of the code
but let us assume that all functions are still at the
same relative offset from start address of code
(in other words: need only a single code pointer)
 
Finally
 
We constructed “weird machines”
 
New spin on fundamental questions:
 
“What is computable?”
Shellcode, ROP, Ret2Libc
 
Turing Complete
 
 
 
That is all folks!
 
We have covered quite a lot:
Simple buffer overflows
Counter measures
Counter counter measures
Research suggests that buffer overflows will
be with us for quite some time
Best avoid them in your code!
Slide Note
Embed
Share

Explore various defense mechanisms to prevent cyber attacks, including proper bounds checking, system defenses like NX bit, Canaries, ASLR, DEP, and techniques like ROP chains. Learn about compiler-level techniques such as inserting canaries on the stack to detect overflows and separating executable memory locations from writable ones.


Uploaded on Sep 07, 2024 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. Part III Counter measures

  2. HOW DO WE STOP THE ATTACKS? The best defense is proper bounds checking but there are many C/C++ programmers and some are bound to forget Are there any system defenses that can help?

  3. HOW DO WE STOP THE ATTACKS? A variety of tricks in combination NX bit Canaries ASLR fin

  4. III.A Canaries

  5. Compiler-level techniques Canaries Goal: make sure we detect overflow of return address The functions' prologues insert a canary on the stack The canary is a 32-bit value inserted between the return address and local variables Types of canaries: 1. Terminator 2. Random 3. Random XOR The epilogue checks if the canary has been altered Drawback: requires recompilation

  6. Canaries

  7. How good are they? Assume random canaries protect the stack

  8. III.B DEP

  9. DEP / NX bit / WX Idea: separate executable memory locations from writable ones A memory page cannot be both writable and executable at the same time Data Execution Prevention (DEP)

  10. Bypassing WX Return into libc Three assumptions: We can manipulate a code pointer The stack is writable We know the address of a suitable" library function (e.g., system())

  11. arg 0xbfffeee8 arg 0xbfffeee4 Stack ret address 0xbfffeee0 0x08048430 System() 0xbfffeedc 0xbfffeed8 Why the ret address ? What could we do with it? 0xbfffeed4 0xbfffeed0 0xbfffeecc 0xbfffeec8 buf 0xbfffeec4 0xbfffeec0 0xbfffeebc 0xbfffeeb8 0xbfffeeb4 0xbfffeeb0 0xbfffeeac 0xbfffeea8 0xbfffeea4

  12. Return Oriented Programming ROP chains: Small snippets of code ending with a RET Can be chained together

  13. Return Oriented Programming ROP chains Small snippets of code ending with a RET Can be chained together -- ret ret &gadget3 &gadget2 &gadget1 stack

  14. How good are they? Assume random canaries protect the stack Assume DEP prevents execution of the stack

  15. III.C ASLR

  16. Let us make it a little harder still

  17. Address Space Layout Randomisation Idea: Re-arrange the position of key data areas randomly (stack, .data, .text, shared libraries, . . . ) Buffer overflow: the attacker does not know the address of the shellcode Return-into-libc: the attacker can't predict the address of the library function Implementations: Linux kernel > 2.6.11, Windows Vista, . . .

  18. ASLR: Problems 32-bit implementations use few randomisation bits An attacker can still exploit non-randomised areas, or rely on other information leaks (e.g., format bug) So (I bet you saw this one coming) .

  19. How good are they? Assume random canaries protect the stack Assume DEP prevents execution of the stack Assume ASLR randomized the stack and the start address of the code but let us assume that all functions are still at the same relative offset from start address of code (in other words: need only a single code pointer)

  20. Finally

  21. We constructed weird machines New spin on fundamental questions: What is computable? Shellcode, ROP, Ret2Libc Turing Complete

  22. That is all folks! We have covered quite a lot: Simple buffer overflows Counter measures Counter counter measures Research suggests that buffer overflows will be with us for quite some time Best avoid them in your code!

More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#