Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

There is a CTF challenge where an attacker can upload and emulate an arbitrary executable inside a sandbox using Qiling version 1.4.1 (the latest version at the time of writing). As such, we need to figure out how to escape the sandbox and ultimately achieve arbitrary code execution. The code for the program is simply a sandbox and the job is to escape it in some way.

Qiling is a binary emulation framework. Under the hood, it uses Unicorn for CPU emulation. However, everything else related to the OS is handled by Qiling. All of the binaries must be compiled statically in order to work within the sandboxed environment. Qiling has implemented most syscalls; this is where the authors of the post decided to look at.

The file system handling is done by concatenating the rootfs name (such as /tmp/mysandbox) to the file inside the sandbox (/tmp/mysandbox/my_file.txt. The application does path normalization to make directory traversal not trivially possible. However, they did not consider that directory traversal could be done within a symbolic link. Hence, the file to access is concatenated with the path from the symbolic link, giving us access to the host file system.

Sadly, the symbolic link syscall was not implemented in the sandbox fully. Back to the drawing board! The syscall openat is similar to open except it has the additional parameter dirfd with it. According to the man page: "If pathname is absolute, then dirfd is ignored." Since the sandbox will pass in the FD and the path, the sandbox can be trivially escaped using an absolute path in the openat syscall.

With the ability to read and write arbitrary files via the mishandling of the openat call, how do we get code execution? To do this, the authors decided to modify the running sandbox process via /proc/mem, which is a virtual file for the processes memory. To do this, they alter LibC with a large NOP sled and some executable code to spawn a shell. With this, there is code execution in the context of the sandbox! The flag is rwctf{s0-many-vu1n_but-only-few-exploitable}, which makes sense from the bug described above.

Pwnable challenges are not always memory corruption; sometimes, they come down to logic bugs. In this case, the path parsing was messed up from a misunderstanding of the openat syscall and the lack of validation done on the symbolic link handling. Great write up for a very interesting bug!