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

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
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
8 emerging trends in container orchestration

8 emerging trends in container orchestration

Containerization is now officially mainstream. A quarter of Datadog’s total customer base has adopted Docker and other container technologies, and half of the companies with more than 1,000 hosts have done so. As containers take a more prominent place in the infrastructure landscape, we see our customers adding automation and orchestration to help manage their fleets of ephemeral containers.

Read More