SystemsSec 2016W Lecture 13: Difference between revisions

From Soma-notes
No edit summary
No edit summary
Line 1: Line 1:
Class Notes
 
Unsafe Language
== Topics & Readings ==
* Reading: Aleph One (aka Elias Levy), [http://www.phrack.com/issues/49/14.html#article Smashing The Stack For Fun And Profit] (Phrack 49, 1996)
* Buffer Overflow Attack
* Memory Corruption Attack
 
== Class Notes ==
 
==== Unsafe Language ====
Defined as languages, such as C, that are susceptible to buffer overflow attacks. Safe languages are not susceptible because they have really strong compilers.
Defined as languages, such as C, that are susceptible to buffer overflow attacks. Safe languages are not susceptible because they have really strong compilers.


Secure systems are not susceptible to overflow attacks because the reference monitor is small enough to verify and remove any bugs. The reference monitor is also resilient due to the fact that it is outside the domain of process execution.
Secure systems are not susceptible to overflow attacks because the reference monitor is small enough to verify and remove any bugs. The reference monitor is also resilient due to the fact that it is outside the domain of process execution.


Memory Corruption Attack
==== Memory Corruption Attack ====
[[File:systemMemory.png]]<br/>
Figure 1: System structure with certain portions of memory re severed for those types
Figure 1: System structure with certain portions of memory re severed for those types


Line 12: Line 20:
A common way to know that your code is vulnerable to a buffer overflow/memory corruption attack is if you get a segmentation fault.
A common way to know that your code is vulnerable to a buffer overflow/memory corruption attack is if you get a segmentation fault.


Classic Buffer Overflow Attack
==== Classic Buffer Overflow Attack ====
The bad code comes from user input (network, keyboard, disk), in the program itself (just run in different way), environment variable.

Revision as of 23:59, 2 March 2016

Topics & Readings

Class Notes

Unsafe Language

Defined as languages, such as C, that are susceptible to buffer overflow attacks. Safe languages are not susceptible because they have really strong compilers.

Secure systems are not susceptible to overflow attacks because the reference monitor is small enough to verify and remove any bugs. The reference monitor is also resilient due to the fact that it is outside the domain of process execution.

Memory Corruption Attack


Figure 1: System structure with certain portions of memory re severed for those types

In a buffer overflow attack you can essentially over write some other portion of memory. For example an attacker may put to much information into the memory portion reserved for string such that it overflows into the memory space reserved for array. Safe languages such as Java are not susceptible to memory corruption attacks unless there is some bug in the compiler.

A common way to know that your code is vulnerable to a buffer overflow/memory corruption attack is if you get a segmentation fault.

Classic Buffer Overflow Attack

The bad code comes from user input (network, keyboard, disk), in the program itself (just run in different way), environment variable.