Outline Memory safety and security CSci 4271W Stack buffer - PDF document

Outline Memory safety and security CSci 4271W Stack buffer overflow Development of Secure Software Systems Day 2: Memory Safety Introduction Reversing the stack Stephen McCamant University of Minnesota, Computer Science & Engineering Other safety problems A large class of problems Ingredient 1: memory unsafety First up, a common class of vulnerabilities in C/C++ Some logical limitations on memory usage are programs generally not automatically checked in C/C++. Motivated by speed, simplicity, history Exist because these languages do not enforce safe Accessing arrays does not check against the size use of memory Program must ❢r❡❡ memory when no longer An attacker who controls program input can make needed, then not use the program do what they want I.e., no garbage collection Language shifts burden to code, code is incorrect Ingredient 2: missing input checks Recipe for safe code Constraints on the untrusted input needed for safety Safe code needs to ensure that for any value of the are not checked untrusted input, nothing unsafe will happen Many normal uses of the program will still work fine From pure security perspective, stopping with an E.g., input size not too large error message is generally safe Attacks occur on inputs that are rare or only an attacker would think of Like other kinds of bugs, easier said than done Usually would have been OK to reject these Safe interfaces or better checks Auditing and testing General strategy: use features and libraries with an Reading code looking for security problems is called inherently safer design a code audit E.g., C++ str✐♥❣ class with automatic memory Often more effective if the reader has fresh eyes management General strategy: add more checks for unsafe or Many security bugs can be found via testing just unexpected conditions Especially randomized automatic testing called fuzzing Allow fewer inputs ✦ fewer attack opportunities

After something goes wrong Mitigation: an arms race At language level, no guarantees about behavior of Modern systems also make many changes to the memory-unsafe code compiler and runtime to try to make attacker’s life C undefined behavior means literally anything can happen harder On real implementations, most unsafe effects ASLR, DEP , stack canaries, . . . more details later understandable from low-level perspective But for performance and compatibility, usually not This is where what you learned in 2021 is relevant complete protections How an attack succeeds in doing something Attackers also have fancier techniques to avoid them interesting is more complex Outline Source-level view (1) Memory safety and security ✈♦✐❞ ❢✉♥❝✭✈♦✐❞✮ ④ Stack buffer overflow ❝❤❛r ❜✉❢❢❡r❬✺✵❪❀ ✇r✐t❡❴✷✵✵❴❜②t❡s❴✐♥t♦✭❜✉❢❢❡r✮❀ Reversing the stack ⑥ Other safety problems Source-level view (2) Demo break 1 Simple palindrome checker: ✈♦✐❞ ❢✉♥❝✭❝❤❛r ✯❛tt❛❝❦❡r❴❝♦♥tr♦❧❧❡❞✮ ④ Short input ✦ correct behavior ❝❤❛r ❜✉❢❢❡r❬✺✵❪❀ Normal too-long input ✦ crash str❝♣②✭❜✉❢❢❡r✱ ❛tt❛❝❦❡r❴❝♦♥tr♦❧❧❡❞✮❀ Malicious too-long input ✦ exploit ⑥ Recall: the stack Overall layout (Linux 32-bit) In compiled C code, local variables and other metadata like return addresses are stored in a memory region called the stack Structured as a stack with one frame of data per executing function Starts at a numerically large address and grows to smaller addresses

Detail: initial stack Stack frame layout Stack frame overflow Demo break 2 How did the attacker know how to overwrite the return address? Outline A possible solution Part of what makes this classic attack easy is that Memory safety and security the array grows in the direction toward the function’s Stack buffer overflow return address If we made the stack grow towards higher addresses Reversing the stack instead, this wouldn’t work in the same way Classic puzzler: why isn’t this a solution to the Other safety problems problem? A concrete example Outline Memory safety and security ✈♦✐❞ ❢✉♥❝✭❝❤❛r ✯❛tt❛❝❦❡r❴❝♦♥tr♦❧❧❡❞✮ ④ Stack buffer overflow ❝❤❛r ❜✉❢❢❡r❬✺✵❪❀ str❝♣②✭❜✉❢❢❡r✱ ❛tt❛❝❦❡r❴❝♦♥tr♦❧❧❡❞✮❀ Reversing the stack ⑥ Other safety problems What might happen in this example, for instance?

Non-contiguous overflow Heap buffer overflow Overwriting a ♠❛❧❧♦❝ ed buffer isn’t close to a return An overflow doesn’t have to write to the buffer in address sequence But other targets are available: For instance, the code might compute a single index, Metadata used to manage the heap, contents of other and store to it objects Use after free Integer overflow A common bug is to ❢r❡❡ an object via one pointer Integer types have limited size, and will wrap around and keep using it via another if a computation is too large Leads to unsafe behavior after the memory is Not unsafe itself, but often triggers later bugs reused for another object E.g., not allocating enough space Function pointers, etc. Virtual dispatch When C++ objects have virtual methods, which Other data used for control flow could be targeted implementation is called depends on the runtime for overwriting by an attacker type Common C case: function pointers Under the hood, this is implemented with a table of More obscure C case: s❡t❥♠♣ / ❧♦♥❣❥♠♣ buffers function pointers called a vtable An appealing target in attacking C++ code Non-control data overwrite Format string injection The first argument of ♣r✐♥t❢ is a little language An attacker can also trigger undesired-to-you controlling output formatting behavior by modifying other data Best practice is for the format string to be a For instance, flags that control other security checks constant An attacker who controls a format string can trigger other mischief