Top 5 Docker Vulnerabilities You Should Know

Offering more than just another buzzword, containers have become one of the biggest trends in software development over the past three years. Developers love their ability to package, test, and deploy their code without the hurdles that can come with transitioning from one environment to another. Leading the pack in the container game has been Docker with its trademark blue whale logo that has become synonymous with container technology. However, despite its popularity, security is still a concern for developers, and unaddressed issues in Docker container security can put your product at risk.

Containers do offer advantages over VMs, but they also introduce a unique container vulnerability profile that teams must manage deliberately. This blog post is part of a series about container security.

Docker vulnerabilities: Container security 101

For starters, containers are isolated software units which makes it harder for malicious actors to escalate from one vulnerability in a containerized application to another or into the OS itself. Docker uses resource isolation features of the Linux kernel like kernel namespaces and cgroups that allow independent containers to run within a single Linux instance.
Second, Docker containers are small and generally focused, but their minimal surface doesn’t eliminate exposure—regular docker image scanning is still essential. All that said, there are still ways that hackers can escape the confines of the kernel with a container breakout flaw and gain access to other parts of your machine or infrastructure, but more on that later when we talk about the runC vulnerability—and why layered controls like kubernetes security best practices matter even when the runtime is patched that caught plenty of headlines in February 2019. Moreover, even as their small size presents a more confined attack surface, their diffuse nature means that there are more moving parts which can be targeted by an adversary.

The reliance on the Linux kernel is at the core of many Docker security vulnerabilities due to the large number of issues associated with it. According to records from 2018, some 180 vulnerabilities were reported to have been found in the Linux kernel that year, leaving many container users open to attacks.

It goes without saying that if your host is compromised, every workload on it is at risk—another reason to pair image hygiene with kubernetes security and cluster hardening.

5 essential docker vulnerabilities

While perhaps not only relevant to Docker’s specific products because as open source reliant technology containers share plenty of the same open source projects at their core, these vulnerabilities have caught more than their fair share of attention over the past year or so.

We’d strongly suggest double-checking patches and also automating detections with Container Security Scanning so regressions don’t slip by.

#1 runC Root Access Remote Execution

Not since the recent Kubernetes security vulnerability in December 2018 has the container-sphere been in such a tizzy.

The open source project runC, which powers the runtime capabilities of nearly all of the container technologies from across the various vendors, was found to have a remote code execution risk due to a container breakout vulnerability that could give the attacker root access to the targeted host. They could accomplish this by overwriting the host’s runC binary.

The containment error, with the CVE-2019-5736 has been upgraded from its initial 7.2 CVSS v3 rating to a more appropriate 8.6 High.
This vulnerability highlighted the risk of attacker-controlled images—and the need to verify provenance before deploy with a pre-release container scan. Docker has released a new version in 18.09.2 which includes a fix that they recommend users upgrade to as soon as possible.

#2 Docker Skeleton Runtime for Apache OpenWhisk

A bit more Docker specific, this vulnerability knocked off quite a number of socks by allowing an attacker to replace the user function inside the container when application code is exploitable—precisely why teams pair code review with image-level checks and container security best practices.

Id’ed by MITRE as CVE-2018-11757, versions of the Docker tag openwhisk/dockerskeleton from 1.3.0 or before were found to be so vulnerable that this Permissions, Privileges, and Access Control CWE picked up a well-deserved CVSS v3 9.8 rating.

Details on the fix in version 1.3.1 are available on the GitHub page.

#3 PHP Runtime for Apache OpenWhisk

It would seem that 2018 was not a great year for Apache OpenWhisk users, highlighted here in CVE-2018–11756.

At the same time that the Skeleton Runtime CVE was making the rounds, this Docker action that inherited the tags before openwhisk/action-php-v7.2:.0.0 or openwhisk/action-v7.1:1.0.1 could allow a hacker to change out the user function inside of the container.

Similar to the Skeleton runtime vulnerability, this CVE is also a Permissions, Privileges, and Access Control issue that due to its extensive potential for havoc, garnered a 9.6 Critical CVSS v3 rating.

The fix can be found as it often is on the project’s GitHub page with version 7.1@1.02. It’s worth noting both attacks depend on vulnerable code in the container, which makes continuous container security tools in CI/CD non-negotiable.

#4 Windows Host Compute Service Shim (hcsshim)

An input validation CWE that threatened a remote code execution, CVE-2018-8115 hit users of Docker for Windows with a particularly nasty threat back when it was disclosed in February of 2018.
According to the reports in May 2018, misuse of filepath.Join could allow RCE on the host—reinforcing the value of signed images and modern docker image security. It received a High CVSS v3 rating, coming in at 8.6.

Thankfully a new version of hcsshim (version 0.6.10) was released by the first week of May, giving developers a safe, patched version. Security researcher Micahel Hanselmann who discovered this particular Docker vulnerability notes that Docker versions CE 18.03.1 and CE 17.05.0-rc1 have the patch included.

#5 util.c in runV

Described as a mishandling of a numeric username, util.c in runV 1.0.0 for Docker was found to allow hackers to gain root access through leveraging the presence of an initial numeric value on an /etc/passwd line and then issuing a “docker exec” command with that value in the -u argument.

For its ability to grant elevated access, CVE-2018-9862 scored 7.8—another case where early detection via automated container scan prevents risky images from reaching production. According to the reports, this CVE was similar to a 2016 Docker vulnerability in runC, CVE-2016-3697 that also granted root access.

Info for the fix can be found here.

Container security tips to reduce docker vulnerabilities risks

As with everything security, start by keeping images current—bake patching into CI and update Docker images on a predictable cadence. The easiest way to do this is through automation and tools that can help to check that you are following best practices.
Docker Bench for Security is a solid baseline—augment it with continuous Container Security Scanning to catch drift and misconfigurations early.

Docker Content Trust (DCT) helps verify integrity; combine signing with encryption and hardened runtimes as part of your broader Docker container security program. Use this tool for signing images, providing them with a level of encryption that can come in handy if your security is compromised.

While some Docker vulnerabilities like we saw in the runC case can give an attacker the ability to break out of the container due to a flaw in the code, there is always the issue of privilege escalations that can result in unwanted remote code executions.
To reduce privilege escalation risk, create user namespaces and enforce least privilege—controls you’ll also apply at cluster scope via kubernetes security best practices, so that are isolated to just as much as your threat model is willing to permit without exposing you to unacceptable risk. We would advise utilizing a limited number of known uids with well-defined roles that do not have root access.

Finally, scan your containers so you know exactly what’s inside—combining docker image scanning with reachability-aware container security best practices to prioritize what’s truly exploitable. One of the primary concerns that have arisen in dealing with containers is a lack of visibility. Pesky vulnerabilities can be hidden away in dependencies which are not easily apparent due to the way that the application’s code is packaged in the container, including known vulnerabilities that would otherwise be caught through other application security testing tools in your SDLC.

Will the sea be rocky or is it smooth sailing ahead?

Still a relatively young technology, Docker and other container services are likely to continue going through growing pains of vulnerabilities.
Despite concerns over Docker vulnerabilities, the shift to microservices continues—just ensure architecture and operations align with strong microservices security and resilient kubernetes security.
Plan ahead with the right strategies and tools—encrypt and sign images, scan continuously, harden clusters, and remediate fast—and those waves become manageable swells, not storms.