Lab 3 - Stack Overflow


Updated: April 8, 2014

I get /lib/ bad ELF interpreter: No such file or directory
If you are using the VM run
sudo yum install glibc.i686
If you are using Ubuntu run
sudo apt-get install ia32-libs
As you should be able to tell from the disassembled code for browser, the SYSCALL instruction works pretty much just like a regular function call. The only difference is that before invoking, $v0 must contain a numeric code for which operating system service should be invoked: 1 for "printi", 2 for "prints", 3 for "putc", and so on. These numeric codes are not standard, but are specific to the cs3410 simulator. Other simulators you might find on the web will use their own numeric codes.
You need the newlines!

Yes, you need the newlines both before and after the "LOL 0wn3d!" message. Of course getting the message in the first place is worth the most points, but the newlines will get you those final few points.

So, an exploit that looks like this:

$ simulate browser < pht24-soln
Where to connect?
LOL 0wn3d! pht24 is on Facebook!
MIPS program exits with status 0 (approx. 8105 instructions in 249071 nsec at 32.32540 MHz)

... is preferable to an exploit that looks like this:

$ simulate browser < pht24-bad
Where to connect?  LOL 0wn3d! pht24 is on Facebook! MIPS program exits with status 0 (approx. 8105 instructions in 252959 nsec at 32.32040 MHz)

As you may have discovered, you can't simply embed a newline or carriage return in the message, because the browser stops reading when it encounters these characters. Something more clever is called for.

Aha! I found this handy vertical tab (0x0b) character! I can just use that instead of a newline, right?

No, a vertical tab is not a newline. You must embed a newline into the message.

Why doesn't my exploit work when I try to use it with the debugger?

The short answer: Use the command simulate -i exploit -d browser

The long answer:

You are likely trying to use one of these two commands:

simulate -d browser < exploit
cat exploit | simulate -d browser

This works just fine without the debugger (simulate browser), but what happens when we run it with the debugger? It takes the contents of the file named exploit and pipes that to the standard input of simulate -d browser... but what input does simulate -d browser expect? The debugger is expecting a command from the user (step, continue, info, etc.). Your exploit code is being used as a debugger command, which confuses the debugger and causes it to exit without executing the browser. The -i flag to simulate will solve this problem.

Don't forget that you can find out about the -i flag and other potentially useful flags by running simulate without any arguments.

My file is on CSUG! How do I get it on my computer to submit it?

If you did your work on the CSUG computers, you should submit your binary exploit file by downloading the file directly from CSUG and submitting that file.

Opening up your binary exploit file in a text editor on CSUG, copying what you see, pasting it into a new file on your computer, and then submitting that will not work.

Why is this? Because your binary exploit file almost certainly contains many characters that can't be printed by the editor you used to view the file with. For example, how do you print a null byte? The text editor can't, so it might replace it with a space, or ^@ (the null byte in caret notation). If you copy that directly into a text file into your computer, those characters don't get converted back. You've just completely messed up your exploit file.

The suggested tool for Windows users to use is WinSCP. You give it the same details as you would give PuTTY, and tell it to download your file.

Mac and Linux users should use scp, a command-line tool. Open up a terminal on your own computer (NOT in SSH!!!) and type something like this:

scp .
#The dot at the end of the command is part of the command. Don't omit it!

This says log in as NETID on csugXX, look for the file named lab3/exploit in your home directory, and download it "here" (that's what the dot means). "Here" probably means the home directory on your own computer, and you can figure out what exactly it is with the command "pwd". On Mac OS X, this is probably some directory named /Users/myUsername. There will be a file named exploit in that home directory. Upload that file.

That said, if you were using Linux...

  1. You probably did all the work natively on your own computer anyway, so don't need to scp anything to/from the CSUGlab computers.
  2. If you didn't already know how to scp, you probably would be able to figure it out via "man scp", otherwise you wouldn't be using Linux.

Users of all OSes should also be able to use FileZilla. Set the connection type to SFTP, and use the same hostname/username/password as you would use for SSH.

I'm really paranoid! How do I make sure I submitted the right file?

After uploading your file, you can make absolutely certain it is the exact same file as the one on CSUG by using the md5 sum. Look at the submission screen on CMS. There is a table that will display a string of hexadecimal characters under "md5".

Log into CSUG, and type in this command:

#Assumes your exploit file is named lab3/exploit.
#Change lab3/exploit to the correct name if it isn't!
md5sum lab3/exploit

It will display a string of hexadecimal characters as well, like this:

63f3dfe77814a22e8f158adbab0a6333  lab3/exploit

If this matches what's on CMS, the file on CMS is exactly the same as the one on the CSUG computers, and you're all done!

If you're sure you downloaded the file from CSUG correctly, and yet the md5 sum isn't matching, we suggest to check whether there's a binary download mode (or something of the sort) in the program you're using to download the file.

Is there a way to get around the command-line arguments limitation?

There are ways to make your program resistant to changes in stack layout. These clever exploits work when the stack starts in some small region, instead of only working for one fixed location. If you implement such an exploit, feel free to brag about it in your documentation for extra credit!

Finally, there is a way to make your program work with any arbitrary stack layout. We'll leave this one for the adventurous. If you find this exploit, again, specify clearly in your documentation what we need to do to see this awesome exploit in action, and you will be awarded more extra credit.