Dear agent, Your task is to obtain root access to the machine deathstar. Rebellion forces have obtained a full clone of the machine, which you can run with the free tool Oracle VirtualBox [1]. At the same time, agents discovered an active login to the system, with the username 'dvader' and password 'luke' (no quotes). [1] https://www.virtualbox.org/ Once you have gained root access to the system, read the contents of the file /root/core_access_codes.txt and report them back to rebellion headquarters via the Fire system. For future reference and reproducibility, also supply the following files: - A description of your exploit. - Any scripts and/or programs you wrote or used. - Instructions how to regain root access, even without the root pwd. - Anything else you think is helpful to reproduce your attack, e.g. ~/.bash_history If you feel like an extra challenge, try to discover the *current* root password on the machine. The system is an old Linux box from the year 2004, running Slackware 8.1. We have reason to believe a vulnerable binary is installed under /usr/bin/addhostalias, with UID and GID bits set to root. Your best bet is to exploit this binary to gain shell access. After logging in under the dvader alias, you will find some helpful material in the home folder: - addhostalias.c The source code to the vulnerable binary - shellcode.h A C/C++ header file with IA32 shellcode in 160 bytes, with no nulls. - shellcode.py A Python script exporting the shellcode as a simple string. This file may be useful if you choose to write an exploit with other tools, e.g. Perl. - instructions.txt This file The system appears to contain suitable versions of gcc and gdb, as well as scripting interpreters such as perl and python, should they be needed. Networking tools such as curl and wget are also available. It is recommended to SSH into the machine, rather than using the console in VirtualBox. The VirtualBox file is set up to forward port 2222 on your host computer to port 22 on the guest system (deathstar). To access it, start the virtual machine in VirtualBox and then, on your host machine, run: $ ssh -p 2222 dvader@localhost You can also use the console in VirtualBox itself, but copying and pasting to the host environment will not work. To help you get started, we suggest you run the addhostalias binary under gdb and inspect its environment. Since the system is old, no address-space randomization is in place, nor is addhostalias compiled with stack protector checks (canaries). The call stack is executable. The binary can be loaded in gdb as such: $ gdb addhostalias Once in gdb, some commands may be of use: run arg1 arg2 ... Run the program with command line arguments, until it exits or a breakpoint is reached. You can use shell expansions in the arguments, e.g. to start a program with the first argument as the output of a script, run run "$(myscript.sh)" break Sets a breakpoint. A symbol name can e.g. be a name of a function in addhostalias.c display/3i $pc Instructs gdb to disassemble and print the next three instructions, both immediately and every time the instruction pointer ($pc) changes. disassemble Shows the disassembled machine code for a function. ni "Next instruction", steps execution by one instruction. A call instruction is executed to completion (i.e. does not step inside procedures) si "Step instruction", steps execution by one instruction, stepping inside procedure calls as well. p/fmt val Prints a value. fmt specifies the format, useful ones are a, c, d and s. See [2] for other formats. Val can be an expression, including register names such as $ebp, $pc, $eax, etc. Example: Print the base pointer: p/a $ebp Prefixing a number to fmt shows multiple values. x/fmt address Examines memory at address. Formats are the same as for p, and i may be a useful one for disassembling machine instructions. Example: Examine the return address of the current function: x/a $ebp+4 Example: Show the three arguments to the current function as pointers: x/3p $ebp+8 info frame Shows information about the current stack frame, e.g. the base pointer, caller address, return address, etc. Notes to keep in mind: - On the IA32 platform, the stack grows "downwards", i.e. items that are higher on the stack have lower addresses. - Stack addresses depend on the environment, e.g. a program started in a SSH session will have different stack addresses than if it was started directly on the console. - Command line arguments are allocated and stored below the stack, so their size will affect stack addresses. - IA32 has little-endian byte order. That means that e.g. the address 0xDEADBEEF will be stored in memory as the byte sequence 0xEF, 0xBE, 0xAD, 0xDE. Some helpful resources: - Linux/IA32 calling conventions and stack disciplines http://www.cs.princeton.edu/courses/archive/spr04/cos217/lectures/IA32-III.pdf Note, the following guides/tutorials are good but very in-depth. Follow them at your own risk, but note that doing so may result in a more complex attack than necessary. - Aleph One's smashing stack-smashing guide http://insecure.org/stf/smashstack.html - Claes Nyberg's guide to buffer overflows http://www.cse.chalmers.se/edu/course/TDA602/usploits.ps