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!

The overlay file system (OverlayFS) allows a user to merge file systems together to create a single unified file system. There are different types of mounts with OverlayFS: lower, upper and overlay in this order. The overlay is the overarching item of the setup. If you write to the lower directories, it will be copied to the upper ones. If you write to the upper, it doesn't go to the lower though. This is a design feature for isolation, it appears. If changes are made through the overlay, they are only reflected in the upper directory.

Recap: lower->overlay, upper<->overlay and lower->upper. When a kernel copies a file from the overlay file system to the upper directory, there is no validation on the owner of this file within the current namespace. Using this oversight, a lower directory could smuggle a SETUID binary into the upper directory using OverlayFS.

How could this be exploited? Let's are below:

1. Create a FUSE file system. This will allow us to create a binary owned by root with the setuid bit on it.
2. Create a new namespace.
3. Create a new OverlayFS mount with the lower directory within the FUSE FS from the previous step.
4. Trigger a copy of our SETUID binary from the overlay FS to the upper directory. This can be done by simply creating the binary. We now have a setuid binary under the upper directory, even though this was from the OverlayFS setup.
5. Exit the user namespace from step 2 to execute the SETUID binary!

The vulnerability allows for a privilege escalation to root by not handling namespaces correctly. This is why defense-in-depth with limiting syscalls and other things is important. Good writeup!