Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Infrastructure Security

2/18/2019
06:00 AM
Larry Loeb
Larry Loeb
Larry Loeb
50%
50%

Container Vulnerability: Still a Reality

A security problem with runC that could allow attackers to\r\nescape Linux containers and obtain unauthorized, root-\r\nlevel access to the host operating system is on the move.

runC is the core run-time container code that lives underneath several open-source container management systems like Docker, Kubernetes, ContainerD and CRI-O. It's widely being used by major cloud hosting and server providers.

However, Aleksa Sarai, a senior software engineer and runC maintainer at SUSE Linux GmbH, has announced a security problem with runC that could allow attackers to escape Linux containers and obtain unauthorized, root- level access to the host operating system.

Sarai said, "the vulnerability (CVE-2019-5736) allows a malicious container to (with minimal user interaction) overwrite the host runC binary and thus gain root-level code execution on the host. The level of user interaction is being able to run any command (it doesn't matter if the command is not attacker-controlled) as root within a container in either of these contexts: creating a new container using an attacker-controlled image or attaching (docker exec) into an existing container which the attacker had previous write access to."

The full details of the vulnerability have not been publicly released to allow vendors to come up with patches before attacks begin in earnest.

There has been some confusion from software vendors as to whether or not their particular containers are vulnerable to this.

Red Hat's Principal Product Manager of Containers, Scott McCarty, has said, "This vulnerability is mitigated by the use of SELinux in targeted enforcing mode, which prevents this vulnerability from being exploited. The default for SELinux on Red Hat Enterprise Linux 7 is targeted enforcing mode and it is rarely disabled in a containerized environment."

But, Sarai notes that, "This vulnerability is *not* blocked by the default AppArmor policy, nor by the default SELinux policy on the "moby-engine" package on Fedora (because container processes appear to be running as container_runtime_t). However, it *is* blocked through correct use of user namespaces (where the host root is not mapped into the container's user namespace). The "docker" package as well as podman are protected against this exploit because they run container processes as container_t."

Debian and Ubuntu have acknowledged that their Linux distributions are vulnerable to this problem. Google, Amazon, Docker and Kubernetes have all issued security patches to deal with the problem.

The researchers that originally found the problem (Adam Iwaniuk and Borys Popławski) have some ideas on mitigating an unpatched runC. They advise:

"1. Use Docker containers with SELinux enabled (--selinux- enabled). This prevents processes inside the container from overwriting the host docker-runc binary.
2. Use read-only file system on the host, at least for storing the docker-runc binary.
3. Use a low privileged user inside the container or a new user namespace with uid 0 mapped to that user (then that user should not have write access to runc binary on the host)."

Tim Mackey, technical evangelist at Synopsis, has reflected on what this vulnerability means to the enterprise.

He told SecurityNow about his concerns for the future of container security, saying that "There are a few ways container malware is most likely to manifest with the most worrisome being a malicious base image. For example, a malicious person could replace a legitimate binary in an image with something malicious, but ideally with comparable capabilities. Then they need to publish that image into a registry and convince someone to use it within their application. Unfortunately, that's still easier than it should be. Then the legitimate app developer merges their app with that malicious base image and you've effectively embedded the malware."

He went on to say, "The next most worrisome is that during development the normal security rules in production are relaxed and you could get some escalation of privilege scenarios that might create container breakout opportunities and get the malicious code within the org. A beachhead could then result."

Finally, "Lastly I worry about poisoning of the host. That could come from any of the above, and might be more difficult to detect given that containers are effectively permitted processes on a machine which could launch other processes."

— Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/2/2020
Ripple20 Threatens Increasingly Connected Medical Devices
Kelly Sheridan, Staff Editor, Dark Reading,  6/30/2020
DDoS Attacks Jump 542% from Q4 2019 to Q1 2020
Dark Reading Staff 6/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-9498
PUBLISHED: 2020-07-02
Apache Guacamole 1.1.0 and older may mishandle pointers involved inprocessing data received via RDP static virtual channels. If a userconnects to a malicious or compromised RDP server, a series ofspecially-crafted PDUs could result in memory corruption, possiblyallowing arbitrary code to be executed...
CVE-2020-3282
PUBLISHED: 2020-07-02
A vulnerability in the web-based management interface of Cisco Unified Communications Manager, Cisco Unified Communications Manager Session Management Edition, Cisco Unified Communications Manager IM & Presence Service, and Cisco Unity Connection could allow an unauthenticated, remote attack...
CVE-2020-5909
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, when users run the command displayed in NGINX Controller user interface (UI) to fetch the agent installer, the server TLS certificate is not verified.
CVE-2020-5910
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, the Neural Autonomic Transport System (NATS) messaging services in use by the NGINX Controller do not require any form of authentication, so any successful connection would be authorized.
CVE-2020-5911
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, the NGINX Controller installer starts the download of Kubernetes packages from an HTTP URL On Debian/Ubuntu system.