In early 2022, security researchers uncovered a vulnerability (CVE-2022-27650) in container runtimes that has affected both the popular Moby (Docker Engine) project and the crun container runtime. This vulnerability exposes a breach in how containers are started, specifically with handling Linux process capabilities. If exploited, it opens the door for attackers to elevate their privileges inside containers—one of the primary things you never want happening in container security.

This post will break down how CVE-2022-27650 works, what causes this flaw, how an attacker could abuse it, how to spot vulnerable containers, and what you can do to defend against it. We'll keep the language simple and include code snippets plus links to further references.

Short summary

When Moby (Docker) or crun start a container, they should strictly control what Linux process capabilities are granted to processes. Capabilities like CAP_NET_ADMIN or CAP_SYS_ADMIN control what the process can do (think of them as more fine-grained root permissions).

In this vulnerability:

Containers could start with a non-empty "inheritable" capability set.

- Programs that already have "file capabilities" (special permissions on their executable file) could use this to get even more rights when they are run inside the vulnerable container.

These capabilities have different sets: *permitted*, *effective*, *inheritable*, etc.

3. Moby/crun didn't empty the *inheritable* set when starting containers.
4. If a process inside the container runs an executable that has some file capabilities set, Linux merges the inheritable set into the permitted set for the new process.

Let's say you're running a Docker container. When you type

docker run --rm -it ubuntu:20.04 bash

You expect processes in that container not to have special admin rights, just like a normal user.

But due to CVE-2022-27650, processes could start with "inheritable" capabilities present—making it possible for sneaky programs with file capabilities to get bumped-up privileges.

Suppose we have a statically compiled ping binary (or any binary) with file capabilities like this

# Outside the container (on host), set file capabilities:
setcap cap_net_raw+ep ping_broken

# Copy into container image or mount into container!

Now from inside the vulnerable container

# As an unprivileged user
./ping_broken 8.8.8.8

*If the inheritable set is not empty*, ping_broken runs with cap_net_raw, allowing the user to send raw network packets.

A minimal C program to check the current caps

#include <stdio.h>
#include <sys/capability.h>

int main() {
    cap_t caps = cap_get_proc();
    char *caps_text = cap_to_text(caps, NULL);
    printf("Capabilities: %s\n", caps_text);
    cap_free(caps);
    cap_free(caps_text);
    return ;
}

Compile and run inside your container—notice the inheritable set is *not* empty unless you’ve patched this bug.

Which versions are affected?

- crun before version 1.4.4
- Moby (Docker Engine) before PR#43563, merged in May 2022

You can check your version

docker --version
crun --version

Run this to see the inheritable capabilities

grep CapInh /proc/self/status

If you see anything other than CapInh: 000000000000000, your container is vulnerable.

Real-World Impact

- Privilege escalation: Any user inside the container could get unintended capabilities, breaking the container's security model.
- Escape fear: If the container is running in privileged mode or mounting sensitive files, the consequences get more serious.

How was it Fixed?

- crun: Version 1.4.4 release notes

The update explicitly clears the inheritable capabilities set on container start.

- Moby: Patch merged clearing these capabilities.

If you use Podman: Make sure you're using a patched version or have updated all your system packages.

How to Protect Yourself

- Upgrade Docker/Moby and container runtime to the latest version.

`sh

getcap -r /

References & Further Reading

- CVE-2022-27650 MITRE entry
- SecLists: crun security advisories
- Moby security patch PR#43563
- Relevant blog from Trail of Bits ("Don't forget your inheritable capabilities")
- crun 1.4.4 release notes

Final Thoughts

CVE-2022-27650 is a great example of how nuanced Linux security controls can trip up even mature open source container projects. If you run containers in production—especially if you run code from third parties or allow users to drop binaries into containers—patch your runtime now.

Keep an eye on both image contents and host runtimes. It's only a matter of time before these subtle bugs get exploited in the wild.


*Exclusive summary by [YourName], June 2024*
*Feel free to share with your DevSecOps team!*

Timeline

Published on: 04/04/2022 20:15:00 UTC
Last modified on: 04/13/2022 17:12:00 UTC