Anatomy of CVE-2019-5736: A runc container escape!

Anatomy of CVE-2019-5736: A runc container escape!

  • May 4, 2019
Table of Contents

Anatomy of CVE-2019-5736: A runc container escape!

On Monday, February 11, CVE-2019-5736 was disclosed. This vulnerability is a flaw in runc, which can be exploited to escape Linux containers launched with Docker, containerd, CRI-O, or any other user of runc. But how does it work?

Dive in! Processes interact with the operating system to perform a variety of operations (for example, reading and writing files, taking input, communicating on the network, etc.) via system calls, or syscalls. Syscalls can perform a variety of actions.

The ones I’m interested in today involve creating other processes (typically throughfork(2) or clone(2)) and changing the currently running program into something else (execve(2)). File descriptors are how a process interacts with files, as managed by the Linux kernel. File descriptors are short identifiers (numbers) that are passed to the appropriate syscalls for interacting with files: read(2), write(2), close(2), and so forth.

Sometimes a process wants to spawn another process. That might be a shell running a program you typed at the terminal, a daemon that needs a helper, or even concurrent processing without threads. When this happens, the process typically uses thefork(2) orclone(2) syscalls.

These syscalls have some differences, but they both operate by creating another copy of the currently executing process and sharing some state. That state can include things like the memory structures (either shared memory segments or copies of the memory) and file descriptors. After the new process is started, it’s the responsibility of both processes to figure out which one they are (am I the parent?

Am I the child?). Then, they take the appropriate action. In many cases, the appropriate action is for the child to do some setup, and then execute theexecve(2) syscall.

Source: amazon.com

Share :
comments powered by Disqus

Related Posts

Dockter: A Docker image builder for researchers

Dockter: A Docker image builder for researchers

Dependency hell is ubiquitous in the world of software for research, and this affects research transparency and reproducibility. Containerization is one solution to this problem, but it creates new challenges for researchers. Docker is gaining popularity in the research community—but using it efficiently requires solid Dockerfile writing skills.

Read More
Containers, Security and Echo chambers

Containers, Security and Echo chambers

There seems to be some confusion around sandboxing containers as of late, mostly because of the recent launch of gvisor. Before I get into the body of this post I would like to make one thing clear. I have no problem with gvisor itself.

Read More
Open-sourcing gVisor, a sandboxed container runtime

Open-sourcing gVisor, a sandboxed container runtime

Containers have revolutionized how we develop, package, and deploy applications. However, the system surface exposed to containers is broad enough that many security experts don’t recommend them for running untrusted or potentially malicious applications. A growing desire to run more heterogenous and less trusted workloads has created a new interest in sandboxed containers—containers that help provide a secure isolation boundary between the host OS and the application running inside the container.

Read More