Project 1 FAQ

CS155, Spring 2007

Q: The terminal text in the video of the TA session is completely unreadable!

Answer: A list of all the commands used can be found here

Q: Where can I find a partner to work with?

Answer: Post to the newsgroup su.class.cs155 on the server

Q: I don't have enough space in my home directory to untar and use boxes.

Answer: We have requested an extra 500MB of quota, but it hasn't been created yet. In the mean time, you can work in /tmp; just be sure to backup your exploits in your home directory, since /tmp is periodically cleaned out.

Update: The extra quota has been allocated.

Q: I'm working in a project in pairs, can I do half the problems and my partner do the other half?

Answer: The spirit of doing the assignment as a pair is that you work on it together at the same time at the same machine. We do not want people from splitting the project into you do a bunch of problems and I do a bunch of problems because that means the other person does not have the experience of solving half the problems. Also, if you don't know how to solve half the problems, you may encounter difficulties in the final if a similar problem is posed.

Q: Can I use another Linux machine instead of the Myth machines?

Answer: You can try but note that the supplied boxes interacts badly with some 2.6 kernel versions. We've verified that the entire project works on the myth machines and that is what we recommend you use--we will not provide technical support for other machines. Also, If you work outside of boxes, you must make sure that the exploits work with the compile toolchain in boxes because that's what we'll be using to grade. No credit will be given for exploits that do not work in the supplied boxes.

Q: When I try "myth10:/tmp/eujin> xterm -e boxes/string &" I get "DISPLAY not set".

Answer: Your ssh session isn't forwarding X windows. If you're using Windows, you'll need to setup VNC. Checkout for more information.

On non-Windows machines, the simplest way to fix this is to run ssh with the option -Y, e.g. ssh -Y user@myth. If you want to set ssh to do this by default, add the line ForwardX11 yes to the file ~/.ssh/config (create the file and directory if necessary and note the initial period in the directory) on your local machine, not myth.

Q: I know X forwarding is working properly, but when I run xterm -e boxes/string & it immediately exits.

Answer: You're probably trying to run it in your home directory, but boxes doesn't seem to work well with AFS directories. Moving boxes to /tmp (which is not AFS) as described in the handout should fix the problem.

Q: boxes doesn't work when run from my home directory.

Answer: We think boxes is incompatible with something in AFS, which is the software used to share your home directory across different machines. As of now there is no solution, so you'll have to work in /tmp.

Q: How do I stop boxes to properly log out of the myth machines?

Answer: Log into the boxes console as root and type "halt". Make sure that nothing important is in /tmp on boxes because that will be wiped clean on startup.

Q: When myth's /tmp gets wiped out, I have to set everything up again. How do I avoid doing that?

Answer: You can try running boxes in your home directory or placing symbolic links in /tmp that point to boxes and the cow1 file in your home, but it probably won't work: boxes seems to crash if it needs to access any AFS directories.

The easiest solution is probably just to backup everything in your home directory and then copy it back to /tmp when it gets erased.

Q: Why can't I use get_sp() to get the stack address in my exploit?

Answer: When you put in a get_sp() on your exploit code, it's getting the stack pointer of the main() function in the exploit code. That stack pointer address is based on, among other things, the environment variables in your shell when you executed sploit1. This address might change depending on what you do in the shell beforehand. So basing your exploit code on this address is not a good idea.

But once main() calls execve, the sploit process gets forked and the text, data, bss, and stack of the calling process (sploit) are overwritten by that of the program loaded (target program). Once we're in this state, the addresses that we obtain from running gdb at this point will not change if you don't change the size of the input arguments (i.e. your exploit string length) or the contents of the env pointer argument to execve. That's why you can safely hardcode your address in your exploit code.