Main navigation | Main content
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.
This will create what we'll call your group directory,
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.
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.
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.
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.
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.
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:
vncviewer -via USERNAME@csel-x5271-xHH.cselabs.umn.edu localhost:PPThe 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.
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.
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.