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!

Apport is the Ubuntu crash handler. When an application crashes Apport is executed by the kernel, reads information about the crashed process, and then creates a crash report that can be sent to Ubuntu developers.

When a process crashes in Linux a core file is created. A core file is the recorded working state of the memory of the process at a specific time. When Apport takes this over, it stores the core file in its own special location with its own parameter. Using a newer feature, the | prior to a user path can be used in order to allow for a userspace program to handle the crash, where the input is given via stdin to the program. Because Apport is running as root when debugging a user space process, it becomes a very attractive attack surface.

Apport is supposed to create a crash report at /var/crash and create a cordump in the directory of the crashed process. When writing a core dump, it takes the formatted stdin to create a coredump file. What if we could issue parsing issues with this? We may be able to control the content and the file write location.

The Apport process normally drops privileges in order to prevent easy privilege escalation. However, by changing the name of the process to contain \r, the parsing of the status file gets messed up, resulting in spoofable content! Now, we can set the UID and GUID to 0 in order to prevent the dropping of the privileges.

With the program running as root, can we cause any other parsing issues? Not quite yet. The program has a check to ensure that the current uid is for whoever created the process, which, because of setuid checks, fails to write the contents of the file. To bypass this check, we start with a setuid program, drop the privileges, then use the trick above. To control the name, we need to use a symlink to the setuid binary.

Apport is given 1 for a regular process and 2 for a setuid process. The setuid process has a core file dump size of 0, results in nothing being written. However, because this validation is based upon a PID, what would happen if we killed the process then replace it with a new setuid process? The final piece to the attack is PID recycling.

Even though the recycling is a good idea, Apport thought of this! They have a validation done by reading the /proc/ file system to ensure that the start time of the process and the old process are the same. However, using the original parsing bug again can be used to manipulate the file check locations.

To eventually get a shell, the authors eventually wrote to /etc/logrotate.d with their coredump. This configuration file change can be used to pop a shell because of the scripts being executed and the non-strict parsing.

This is a super awesome collection of bugs but all stems from bad parsing because of improper parsing of newlines and spaces. Parsing is hard to do properly.