Lecture 3: Memory Safety Vulnerabilities

• Slides
• Playlist (length: 1:16:12)
• Optional: Some students have found these slides from Matthias Vallentin helpful: Normal x86 function call, a crash, a control-flow diversion, and code injection.

Buffer Overflow Analogy

What part of the airline ticketing system might be broken? How might you fix it?

In the system, your name and your airline class are stored in consecutive blocks of memory. However, if you enter a really long name, the system doesn’t check that your name is too long, and your name starts to overflow into the memory space used to store your airline class. To fix this, the system might reject any names that are too long.

Vulnerable Code

In the last example of vulnerable code (with a function pointer), what should the attacker input as their name to take over control of the program? Assume the code the attacker wants to run is more than 20 bytes long.

The attacker should input 20 bytes of garbage (anything), followed by the address of the attacker’s code, followed by the attacker’s code. The address of the attacker’s code is the next address just after the address of the function pointer.

Memory-Unsafe Languages are Dangerous

What are the four parts of C memory? What part of memory would a variable be stored if I define it: 1) outside any function, 2) as a local variable in a function, and 3) by calling malloc?

From lowest address to highest: code, static, heap, stack. A variable defined outside any function would be stored in static memory. A local variable defined in a function would be stored on the stack. A variable defined by calling malloc would be stored on the heap.

Note: The 61C review lecture has a review of C memory layout if you want a refresher.

x86 Function Call

What two values are saved on the stack when x86 calls a function? Why do we need to save these values?

First, we save the return address, because when we transfer control of the program to the function, the function needs to know where to transfer control after it’s finished executing. Also, we save the old value of EBP on the stack, because when we create a new stack frame for the new function, the old EBP will be overwritten with the new EBP. When the function returns, it will restore the old saved value of EBP.

Note: For more details on x86 function calls, consult the 61C review lecture.

Intro to Buffer Overflows

Overwriting the Return Address

Suppose there is a vulnerable local variable that the attacker can overflow at address X on the stack, and the return address of this stack frame is at address Y. What could the attacker input into the buffer to take over control of the program? (You can use expressions like X+Y or Y-12 in your answer.)

First, the attacker writes Y-X bytes of garbage to fill up all the space between the buffer and the return address. Then, the attacker writes the address Y+4 into the return address, because the return address is 4 bytes long, and the attacker’s code will be inserted directly after the return address. Finally, the attacker writes their code.

Signed/Unsigned Vulnerability

Note: You don’t need to know the specifics of number representation for projects or exams. You should know that 0xffffffff (a binary string of all 1s) is a very large number when interpreted as an unsigned integer, and -1 when interpreted as a signed integer.

Integer Overflow Vulnerability

Format String Vulnerability

Q2 on Homework 2 has some practice on format string vulnerabilities.

Vulnerabilities Outside the Stack

Note: You should know conceptually that the heap can be overflowed in C++ to take control of the program, but since C++ is not a prerequisite for the course, we won’t test you on C++ heap overflows on exams or projects.

Making Exploits Robust

What are some defenses we might use to stop buffer overflow attacks?

Some possible ideas: Use a memory-safe language, like Python, Java, or Go. Carefully check that every memory access doesn’t read or write past the end of a buffer. Make memory addresses unpredictable. The next lecture will introduce you to some common defenses against buffer overflow attacks.