CS 642 - Introduction to Information Security - Spring 2019

Stack overflows
1. Does the call instruction go right before the string containing the program name, or right after?
2. Why does the attack code have to null-terminate the program name?
3. Why can we run our own program to get the stack pointer -- shouldn’t we have to get the stack pointer from the target program?
4. What are the program features you need as an attacker to launch a successful stack overflow?
5. More generally, what are the capabilities you need as an attacker to launch this kind of control-flow attack, where you cause the target program to execute code you as the attacker provide?
Finding vulnerabilities:
1. Why is it important to look at the assembly code for a program when developing attacks or looking for vulnerabilities, instead of just looking at source code?
2. When is a tool that is sound but not complete acceptable?
3. When is a tool that is neither sound nor complete acceptable?
4. The double free vulnerability depends on implementing a heap with a linked list. Another way to implement a heap is to have a separate bitmap, stored away from user data that records, for each block of memory in the heap, whether it is allocated or not. Is this heap implementation vulnerable to double-free attacks, and if so, how?
5. Given a program with a double free bug, what kind of tool would be most appropriate to find it:
  1. Fuzzing
  2. Symbolic analysis
  3. Scanning
  4. Dynamic analysis
6. A key metric for automatic analysis is coverage: how much of the code is executed.
  1. Give a code example showing a bug where basic block coverage would indicate the code had been fully tested, but the bug still exists.
  2. Give a code example showing a bug where path coverage would indicate the code had been fully tested, but the bug still exists.
Memory protection
1. Will non-executable stack pages (W xor X) protect against the Aleph-one buffer overflow attack? What if the attack code is placed in an environment variable instead of on the stack?
2. What are the features an attacker needs to execute an arbitrary algorithm?
3. What kind of program bugs allows return-oriented programming?
4. For address-space layout randomization, is it ok if every program on the same computer uses the same layout? Explain.
Return-oriented programming
1. Describe the characteristics of a gadget
2. What does an ROP program look like?
3. Describe the gadgets needed to execute “system(“/bash/sh”): how do you:
  1. Pushing the shell string on the stack
  2. Executing system()
Stack Canaries
1. A typical program with a buffer overflow will segfault (crash) when given input is too long. With stack canaries, what will happen with input that is too long?
2. How can a double-free vulnerability be used to defeat stack canaries?
3. Does the same approach work with stack ghosting (XORing a value with the return address)?
Sandboxing
1. Suppose you trick the mount setuid program, which reads from the /etc/mounts file to find allowed devices to mount, to run in a chroot jail. Explain how you could make mount work with a device of your choosing
2. Suppose you want to download a game off the web and run it, but prevent it from accessing your files. How could you use a chroot jail for this?
3. System call interposition, as with Janus, places extra checks on system calls. Explain how it can prevent the stack-overflow attach to execute a root shell. What system calls would you check, and what parameters would you allow/disallow?
4. You want to use virtualization to protect your system. Can you use it to protect against buffer overflows in setuid programs? Can you use it to protect against buffer overflows in a web server?

Low-levelReview