SystemsSec 2016W Lecture 13: Difference between revisions
Hassansaid (talk | contribs) No edit summary |
Hassansaid (talk | contribs) 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
- Reading: Aleph One (aka Elias Levy), 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.
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.