Project 1 FAQ

CS155, Spring 2007

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

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

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

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".

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.