Lecture 4: Buffer Overflow Defenses

• Slides
• Optional slides
• Playlist (length: 45:36)

Ensuring Memory Safety

Optional: Reasoning About Memory Safety

One way to ensure memory safety is to carefully reason about memory accesses in your code, by defining pre-conditions and post-conditions for every function you write and using invariants to prove that these conditions are satisfied. Although it is a good skill to have, this process is rarely used in practice, so it is out of scope for the summer.

If you are interested, the Spring 2020 video is linked below. It will not be tested on any exams or projects.

(End of optional content. Everything below this is in scope.)

Use a Memory-Safe Language

True or false: Using a memory-safe language prevents 100% of buffer overflow attacks.

True. If the language is designed with bounds checking, there is absolutely nothing an attacker can do to cause a buffer overflow. Of all the defenses discussed in this lecture, using a memory-safe language is the only one that prevents 100% of buffer overflow attacks.

Defending Non-Memory-Safe Code

Stack Canaries

An attacker runs a vulnerable program with some input that leaks the stack canary, and writes down the value of the leaked stack canary. Then the attacker runs the program again, using the leaked canary value to overwrite the stack canary. True or false: this strategy defeats the stack canary defense.

False. The stack canary changes every time the program is run. The attacker would need to learn the value of the stack canary and overwrite the canary with the leaked value in one single execution of the program. (This is what you will do in Project 1!)

Guessing the Canary

How many bits of entropy would a canary on a 64-bit system have if one of the bytes is always 0x00?

One byte is 8 bits, so the canary would have 64-8=56 bits of entropy.

Non-Executable Pages

True or false: An attacker cannot do anything malicious if non-executable pages are enabled. (Hint: Think about the analogy from the last lecture.)

False. An attacker can still overwrite local variables, like in the first class airplane ticket example from the previous lecture. Non-executable pages do not prevent this because the attacker isn’t executing any instructions on the stack. The next video introduces another way to defeat non-executable pages.

Return Into libc

Return-Oriented Programming

Why does enabling non-executable pages not prevent return-oriented programming?

Return-oriented programming is running code gadgets that already exist in memory. Non-executable pages only stop an attacker from executing code that the attacker has written into memory.

Address Space Layout Randomization (ASLR)

True or false: If ASLR is enabled but DEP is not enabled, an attacker can write malicious code to the stack and overwrite the return address to execute that code.

False. The attacker wouldn’t know the address of the malicious code to overwrite the return address with. However, if the code had some vulnerability that leaked addresses, this attack might work.

Defenses in Practice

Fuzz Testing

Memory Safety Conclusion

After finishing this lecture, you should have everything you need to start Project 1. Debugging this project can be time-consuming, so please start early!