Hands-on Assignment 1 virtual machine instructions

Hands-on assignment 1 is about exploiting bugs in a poorly written program in order to take control of a Linux system. In order to make this realistic but still not have you interfering with each other or taking over CSE Labs machines, you'll test out your attacks using a virtual machine that we've set up. These VMs will be spread across a cluster of network-accessible machines run by CSE Labs. This page gives directions and some hints about how to use your VM effectively.

Getting started instructions

1. To start, send an email to the TA (Travis Carlson, carl4980 AT umn.edu) requesting a VM, giving the names and UMN IDs (@umn.edu email addresses) of your group members, remember no more than 3.
2. You'll get a reply from the TA, assigning your group some unique identifiers. Specifically your group will have three numbers: in the discussion and sample commands below, we'll write these numbers as GG, HH, and PP, so whenever you see those you're supposed to fill in your group's numbers. GG is a unique number for your group, ranging from 1 to the number of groups we have (probably no more than 50). HH is number of the computer your VM will run on (H for "host"); as of this writing we've been assigned computers 01 through 04. Finally PP is a number, probably between 11 and 19, telling which network ports your machine's VM will use on the machine. Neither HH nor PP is unique to your group, but the combination of the two will be.
3. SSH into the machine csel-x5271-xHH.cselabs.umn.edu where HH is the host number mentioned before. Then run the command:

   /export/scratch/csci5271/ha1/master/setup-vm

   This will create what we'll call your group directory,

   /export/scratch/csci5271/ha1/groupGG

   and put in it a fresh virtual machine disk image file named ha1.qcow2. The disk image is about a 3GB file, so copying it will take 10-60 seconds.

4. For convenience, change directory into your group directory. The remaining special commands will be set up as symlinks in this directory so you can run them with "./".
5. Start your VM for the first time using the command ./run-vm. This command will take over your terminal, and print some reminders, but you won't see any messages directly from the boot process. It may take a minute or two, but soon after you see the login: prompt printed in the terminal, you'll be ready to go on to the next step.
6. The recommended way to log into your VM is with SSH from a different window. The ports used by your VM are probably blocked by the department firewall, so you can't SSH in directly from anywhere, but you should be able to SSH in from any CS or CSE Labs machine on the Keller Hall wired network. The most natural place to SSH from is your assigned xHH machine. You should use the command:

   ssh -p PP22 student@csel-x5271-xHH.cselabs.umn.edu

   Where PP and HH are replaced with the port and host numbers mentioned above.

   The VM comes with an account named student which is set up for your use. Initially the password for the account is loans, but you'll need to change the password the first time you log in. Share the password with the other members of your group, but not with anyone outside your group. Specifically on the first time you'll have to type the old password loans twice, then your new password twice, then log in again with the new password.

7. The student account has the ability to run commands as root using the sudo command, so you're generally free to administer the computer as you see fit. For instance if you'd like you can create separate accounts for each group member, you can. There's a pre-created account test that you can use as a clean, unprivileged account for testing exploits. To start it's not set up with a login password, but you can change the password with the command sudo passwd test.
8. BCMTA is installed in /usr/bin/bcmta, and it is also set up to listen on the usual SMTP TCP port. There's also a copy of the source code and Makefile in /src. But note that the copy of the binary in /src is not setuid.
9. For editing binary files, it's convenient to use a tool known as a ``hex editor'': a variant of a text editor that is specialized for binary files instead of text, for instance showing byte values in hexadecimal. The hd command will print the contents of a file in hex. We've installed a number of terminal-mode hex editors you can try running within the VM: for instance hexer has a vi-like interface; tweak has an Emacs-like interface (and there's also hexl-mode in Emacs itself), and shed has a beginner-oriented interface. There's also beav, dhex, hexcurse, hexedit, hte, le -h, and hexeditor.
10. The VM simulates a 64-bit processor and is running a 64-bit kernel, but BCVI is compiled as a 32-bit program to better match our class discussions and older tutorials. To compile your own code in 32-bit mode, you need to pass the -m32 option to GCC, or the -32 option to as.
11. When you're done using the VM for a while you should turn it off. The recommended way of doing this is by running the command sudo halt -p (or sudo shutdown -P now is equivalent) inside the VM.

Don't interfere with other groups and users

Please remember that the machines the VMs are running on are a shared resource used by many other students at the same time. Don't take up so much memory, CPU, or disk space that other students can't use the machine. You're responsible for keeping your VM secure, such as by keeping passwords secret. But you're also responsible for not interfering with other groups' VMs. Hacking into another group's VM is definitely not part of the assignment. Because VM disk images are large, please don't store them on other CSE Labs machines or run QEMU on machines other than the one you've been assigned (to help you remember this, the CSE Labs staff have conveniently not installed QEMU on most other machines).

To encourage you not to leave your VM running when you aren't using it, we've set it up to shut itself down if it's left running unattended overnight (specifically, at about 4am). If you really are using the machine at that time you can cancel the shutdown with the command sudo shutdown -c.

Advanced SSH setup

The simplest way to connect to your VM is to SSH first into your csel-x5271-xHH host machine, and then from there into the VM. You can also copy files in two steps this way using the scp command: note that the option to scp for changing the port is a capital -P, as opposed to ssh's lowercase -p. However if you're copying files a lot you may find that you get tired of typing all of these commands. Of course you can write a short script or use shell variables to abbreviate commands. But the best way to save yourself typing, because it also is more secure, is to use extra features of SSH.

A better practice than SSHing first from one machine and then to another is to ask the first machine to just proxy your SSH connection to the second machine. For instance, one benefit is that the machine in the middle never has to see your password for the second machine. You can set this up by putting the following two commands in your .ssh/config file on your client machine:

Host vm-via-xHH
  ProxyCommand ssh USERNAME@csel-x5271-xHH.cselabs.umn.edu netcat localhost PP22

Here USERNAME is your CSE Labs username, and HH and PP are host and port numbers as usual. Then you can use the command ssh student@vm-via-xHH to connect to the VM's student account.

If you make just the change described above, it will still ask you to type two passwords. But you can combine this with another technique to avoid typing passwords, which is to create an SSH key pair. This approach uses public key cryptography to create a matched pair of a private key and a public key. You put the public key on the machines you want to log into, and load the private key into to memory of the machine you're coming from using a command named ssh-agent; then SSH will automatically use the private key to authenticate you in place of a password. There's a few different steps involved in setting this up, but there are a number of tutorials you can read on the web; one pretty good on is on the Ubuntu wiki.

Testing exploits in a clean environment

You can set things up in your VM the way you'd like, but your exploits can't depend on anything special you've set up in the student account or on the VM, since that would make things harder for us to understand and grade your attack. (And of course since you have root access, you could install extra security holes on your VM, but that's not what we want to evaluate.) You can use the test account for a clean user environment within your VM.

But for the a completely clean test, we'll use a snapshot of a freshly installed VM's test user. For your own testing purposes we've also given you access to this same kind of environment using a script named test-exploit you can find a symlink to in your group directory. Write your exploit as a bash shell script with a name like exploit-42.sh, and then run the command ./test-exploit exploit-42.sh which will start a temporary VM and run your script on it for up to 60 seconds. Your exploit is considered successful if it runs /bin/rootshell as root within that time period.

Note that this means your exploit has to work using the software that's installed on the VM image to start. We've tried to include most of the things that would be useful, such as several different shells and scripting languages. You can install extra software on your VM image if you want to use it in developing your exploits, but your final exploit can't depend on anything special outside the exploit script.

Avoiding and recovering from problems

Your virtual machine should never be the only place where you have a copy of your work. Part of the reason for this is that because of their size, we store the disk images on a "scratch" disk partition that is not backed up: if that disk were to have a hardware failure, all your VM images could be lost. So you should keep copies of your exploit scripts in other places, such as your CSE Labs home directory (which is backed up) or other machines of your own. However from our past experience the more likely things to go wrong are in the running of your VM: in trying to attack it you might mess up its configuration so that it no longer works correctly. So here are some suggestions for avoiding or recovering from that:

• Before conducting a dangerous attack from one window, make sure you have another window already open in which you have a root shell running (e.g., sudo /bin/bash). That way if something goes wrong that interferes with, say, logging in, you can fix it using that shell. You might also want to make backup copies of files before you attack them; a backup copy of the configuration files in /etc as they were in the original VM image is in the directory /etc-backup.
• Your VM disk image is just a regular file, so you can make a backup of it with cp. But it's pretty big, so please don't keep more than 1 or 2 extra copies at once.
• All of the changes made while running the test-exploit script are not saved, so you can experiment freely inside it, though it's not so convenient for debugging what went wrong.
• You can also get a similar affect as with test-exploit for your main VM by giving the option -throwaway to run-vm. When you start the VM with this option, all of the changes you made to the virtual disk will be discarded when the VM shuts down. Of course you definitely want to keep your exploit script elsewhere if you do this!
• If you lose the ability to log into your VM's student account, but the VM is otherwise working okay, the course staff have their own accounts that also have sudo access, so they should be able to reset your password.
• If you've messed up your VM in a serious way, but you have backups of all the important data, the easiest way to fix it may be to start over from a fresh VM. If you remove your ha1.qcow2 file and run the setup-vm script again, it will give you a fresh disk image. Of course the disadvantage is you'll have to redo anything you did inside the VM.
• If you've messed up your VM badly but still have important information on it, you can potentially recover it in the same ways you would with a physical Linux machine: by booting in "recovery mode", using a "rescue CD" to boot, accessing the disk image with another VM, etc. However these are all somewhat complicated, so it's best to avoid this situation by using the techniques above. If you want to boot your VM in a non-standard way, you will probably want to access the VM's console over VNC, which you can do with a command like

  vncviewer -via USERNAME@csel-x5271-xHH.cselabs.umn.edu localhost:PP

  The bootloader screen is only visible for 10 seconds, so you may want to get the VNC client almost ready to run before starting the VM.

If you want to run the VM on your own machine

The VM image and the scripts we use to run it for this assignment aren't secret, so in theory it would also be possible to run the VM on a non-CSE Labs machine using QEMU or another VMM such as VMWare or VirtualBox. However this is not a configuration supported by the course staff, so if you want to try it you're on your own. And in the case of any discrepancy you'll be graded according to how your attacks work on the CSE Labs machines, so be sure to test before you submit.

If you have more questions

Please don't hesitate to ask questions if you get stuck while trying to manage your VM, etc. If the question is one that everyone in the class can benefit from hearing the answer to, the best place to ask it is on the Canvas discussions page. If you have a question that should be answered privately, please send it to both of the course staff using the email addresses on the syllabus to ensure the most prompt response. Technical problems with the VMs should generally go to the course staff first rather than the CSE Labs administrators, since we know more about how the VMs work, but we'll know if we need to enlist them.