EvoSec 2025W Lecture 10: Difference between revisions
Created page with "==Discussion Questions== * What is the basic model behind both of these systems? Hint: focus on the figures! * What aspect(s) of security are these models capturing? What are they missing? Today you'll be teaching the class, i.e., I'll be asking questions as if I don't understand things." |
|||
| Line 1: | Line 1: | ||
<pre> | |||
Lecture 10 | |||
---------- | |||
- areas of interest are all graded | |||
- please read feedback and follow up as necessary | |||
- message on Teams, we can have a call if necessary | |||
What is the basic approach to diversity taken by the Forrest paper? | |||
- the program source code is a "spec" <-- how it SHOULD behave | |||
- vary how it is translated into an executing program | |||
(as source doesn't specify this precisely) | |||
- memory layout, instruction set, function/system call names and more could vary | |||
So with this approach, what is not diverse? | |||
- the source code! | |||
If the source code is always the same, what kinds of security vulnerabilities CANNOT be addressed with Forrest's approach? | |||
- algorithmic weaknesses (e.g. cryptography) | |||
- higher-level code injection attacks will still work (e.g., SQL injection) | |||
- authentication bypass because of insufficient checks | |||
In fact, most security vulnerabilites won't be impacted by changing how the code is translated | |||
It can really only stop attacks based on machine code injection & timing attacks (MAYBE) | |||
What is the difference between diversity and randomization? | |||
randomization | |||
- uniform selection from a set of possibilities | |||
- always has to be limited as random programs don't do anything | |||
- in practice, can only randomize what isn't functionaly important | |||
diversity is always about functional diversity | |||
- variations that make the system behave differently | |||
- but can "fit" into its role | |||
diversity is always relative, never absolute | |||
To understand diversity, we have to understand the problem it addresses | |||
What is an attack search space? | |||
</pre> | |||
Revision as of 18:00, 6 February 2025
Lecture 10
----------
- areas of interest are all graded
- please read feedback and follow up as necessary
- message on Teams, we can have a call if necessary
What is the basic approach to diversity taken by the Forrest paper?
- the program source code is a "spec" <-- how it SHOULD behave
- vary how it is translated into an executing program
(as source doesn't specify this precisely)
- memory layout, instruction set, function/system call names and more could vary
So with this approach, what is not diverse?
- the source code!
If the source code is always the same, what kinds of security vulnerabilities CANNOT be addressed with Forrest's approach?
- algorithmic weaknesses (e.g. cryptography)
- higher-level code injection attacks will still work (e.g., SQL injection)
- authentication bypass because of insufficient checks
In fact, most security vulnerabilites won't be impacted by changing how the code is translated
It can really only stop attacks based on machine code injection & timing attacks (MAYBE)
What is the difference between diversity and randomization?
randomization
- uniform selection from a set of possibilities
- always has to be limited as random programs don't do anything
- in practice, can only randomize what isn't functionaly important
diversity is always about functional diversity
- variations that make the system behave differently
- but can "fit" into its role
diversity is always relative, never absolute
To understand diversity, we have to understand the problem it addresses
What is an attack search space?