Answer: A list of all the commands used can be found here
Answer: Post to the newsgroup su.class.cs155 on the server nntp.stanford.edu.
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.
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.
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.
"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 http://unixdocs.stanford.edu/moreX.html 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
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.
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.
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.
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.
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.
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.