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!

runc mount destinations can be swapped via symlink-exchange to cause mounts outside the rootfs - 516

champtarPosted 4 Years Ago
  • Kubernetes (K8S) is a container orchestration platform used with containers such as Docker. Being able to escape containers is a big deal, as the main idea behind them is user isolation.
  • The author of this article was troubleshooting some container is K8S. Because this code required a bunch of writes to local disk, they added a tmpfs in order to make their life easier. Later on, they noticed that the mount point was mounted at /run instead of /var/run.
  • Because /var/run is a symlink to ../run the author had an interesting question: how does containerd/runc ensure that moutns are inside the container rootfs?
  • While diving into the code, there is a comment that mentioning there is a race condition here IF it is possible to swap the mount out with a symlink. Interesting! This bypasses the function securejoin.SecureJoinVFS check to ensure the mount is within the proper host.
  • The reason for this issue existing is that when Docker/runc was first crated, they did not consider untrusted container definitions as part of the threat model. With K8S, the mount file can be altered to be a symlink to somewhere else.
  • To trigger this vulnerability, we use the fact that we have control over the mount target but not the mount source. Because of this, we can mount a directory containing a symlink over a K8S volume. Then, on the next mount, use this as the source to give access to the root file system.
  • This race condition can be exploited by continually swapping between the directory name and the symlink with the tmpfs in a C binary. While running this code, start another container and hope that the name swap as done at the perfect time to bypass the security check but have the wrong location.
  • The exploit took a fantastic understanding of how Kubernetes and containerization work (a lot of which is over my head). Additionally, the POC took several different attempts to get right, which goes to show that exploitation is difficult even for the smartest people out there.