Back when I was a student, my assignments for the Binary and Malware Analysis course (part of the Systems and Security MSc program at the VU in Amsterdam) had to be submitted using “vmchecker”, an automated homework checking tool.

Assignments were submitted as a zip file; the vmchecker system would unpack them inside a VM, and then unpack a “tests.zip” file which contained the tests, and then run ‘make’. Unfortunately, this file was stored in the same directory which my assignment was unpacked into; I could simply provide my own version of “tests.zip”, containing my own Makefile, and achieve arbitrary code execution inside the VM.

I uploaded a trivial proof of concept to make sure it worked, and pinged the TA responsible for maintaining the system. He fixed it pretty promptly, and also fixed another issue that I pointed out at the same time: a student wanting to cause trouble could provide a zip file which unpacked to a huge size, a primitive DoS (denial of service) attack on the checker system. These fixes were merged upstream around the same time.

One serious problem remained: I couldn’t remember my password for the system, and it wouldn’t let me change it. Thankfully, an unintended “feature” came to my rescue: vmchecker provided an autologin system, which allowed automated scripts to authenticate with the system without requiring a password. It authenticated them using a simple check: did the connection attempts come from the local machine, i.e., from localhost?

Unfortunately, the deployment at the VU was done using a proxy web server, and so all the connections came from localhost, allowing me to (ab)use this feature for several weeks until it was turned off and I was forced to actually hunt down my password when I wanted to submit homework. This bug was eventually fixed by simply removing the feature.