P1:L2 Software Security Flashcards
Buffer (or memory) Overflow
A common and persistent vulnerability
In information security and programming, a buffer overflow, or buffer overrun, is an anomaly where a program, while writing data to a buffer, overruns the buffer’s boundary and overwrites adjacent memory locations.
Stack buffer overflows
In software, a stack buffer overflow or stack buffer overrun occurs when a program writes to a memory address on the program’s call stack outside of the intended data structure, which is usually a fixed-length buffer.
stacks are used
- In function/procedure calls
- for allocation of memory for
- local variables
- parameters
- control information (return address)
Vulnerable password checking program
Not good to hardcode password in code
Push and pop
Push = Stack grows Pop = Stack shrinks
Password check code quiz
Too much data gets stored in the variable for int Remember memory (or buffer) overflow
So… variable could possible be different from 0
Bad input caused a manipulation
Which vulnerability applied to the code in example quiz?
The code did not check the input and reject password strings longer than 12 bytes.
Creates a shell which allows it to execute any code the attacker wants
Shell Code
ShellCode
Has to be stored in memory… instructions… assembler language.. translated into machine code.
Whose privileges are used when attacker code is executed?
- The host program’s
- System service or OS root privileges
“Keys to the kingdom”
How many CVE vulnerabilities does NVD have?
NVD = National Vulnerability Database
CVE = Common Vulnerability and Exposure)
Close to 70,000
How many buffer overflow vulnerabilities reported in the last 3 months
Close to one hundred
How many buffer overflow vulnerabilities in last 3 years?
Over a thousand
The return address is overwritten to point to a standard library function
Return-to-libc (write type)
This is a type of Buffer Overflow (a variation of)
Data stored in the heap is overwritten. Data can be tables of function pointers.
Heap Overflows (write type) (another variation of Buffer Overflow)
Read much more of the buffer than just the data, which may include sensitive data
OpenSSL Heartbleed Vulnerability - a read-only overflow vulnerability which is dangerous if sensitive data is exposed.
(once again, another type of Buffer Overflow)
Good defenses against Buffer Overflow Attacks
*Programming language is crucial
The language should be....
*strongly typed
*automatic bound checks
*Automatic memory managementExamples of “Safe languages”
Java, C++
OO languages make the problems above go away
Why are some languages safe?
Buffer overflow becomes impossible due to runtime system checks
What are drawbacks of secure languages?
Possible performance degradation
What if you are stuck with language that does not auto check? Usage language that does not prevent buffer overflows?
- Check input (ALL input is EVIL!)
- Use safer functions that do “bounds checking”
- Use automatic tools to analyze code for potential unsafe functions.
Strongly or Weakly typed?
Any attempt to pass data of incompatible type is caught at compile time or generates an error at runtime.
Strongly
Strongly or Weakly typed?
An array index operation b[k] may be allowed even though k is outside the range of the array.
Weakly
Strongly or Weakly typed?
It is impossible to do “pointer arithmetic” to access arbitrary area of memory.
Strongly
Analysis tools…
- Can flag potential unsafe functions/constructs
* Can help mitigate security lapses, but it is really hard to eliminate all buffer overflows
Stack canaries
When a return address is stored in a stack frame, a canary value is written just before it. Any attempt to rewrite the address using buffer overflow will result in the canary being rewritten and an overflow will be detected.
ASLR
Address Space Layout Randomization
Randomizes stack, heap, libc, etc… This makes it harder for the attacker to find important locations (e.g. libc function address)
Non-executable stack
Can be used with ASLR - This solution uses OS/harwdare support.
Do stack canaries prevent return-to-libc buffer overflow attacks
Yes
Relies on re-writing return address… the canary will detect to see if the return-stack is modified
Does ASLR protect against read-only buffer overflow attacks
No
Makes it harder to guess where certain variables are… but does not prevent 100%
Can the OpenSSL geartbleed vulnerability be avoided with non-executable stack?
No
A read-only overflow: Doesn’t need to execute… only needs to read.
