Top 5 Docker Vulnerabilities You Should Know
Table of Contents
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 with Docker vulnerabilities out in the wild that can put your product at risk.
Containers come with a number of security advantages that give them an edge over your more common operating systems or even virtual machines (VMs).
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 software units that by design do not offer much in the way of ports that can be compromised or places to hide more complex malware.
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 recent runC vulnerability 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, then all the containers that are using it are also at risk.
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 would strongly suggest double checking with your team that you have patched any of these issues in your own containers, just in case something might have slipped 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 other situations where an attacker was able to break out beyond the isolation of a container that they had succeeded in controlling in order to gain access to the host.
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 of the container if the user’s code is vulnerable to code exploitation.
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 is worth pointing out that despite the high ratings for this CVE as well as CVE-2018-11757, both attacks are dependent on the code inside of the containers to also have vulnerabilities.
#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, the use of the filepath.Join Go function could allow for remote code execution on the host file system. 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 give an intruder a high level of access, CVE-2018-9862 picked up a 7.8 CVSS v3 rating.
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, your first steps should be to make sure that your applications are up to date with the latest patched versions. The easiest way to do this is through automation and tools that can help to check that you are following best practices.
Docker has been nice enough to provide one such tool with their Docker Bench for Security which is available on GitHub.
Then there are great Docker tools like the Docker Content Trust (DCT) which can come in handy for avoiding those Man-in-the-Middle attacks while you are moving your Docker containers around the network. 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 your risk of unauthorized users moving above their paygrade or a lucky hacker who made it past your preliminary defenses, limit the capabilities of what each Docker container is allowed to do by creating user namespaces 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 to know what you are using in them. 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, their potential for helping organizations move to micro-services models and navigate the sea of DevOps with agility will only help grow their popularity.
Hopefully, so long as Docker users plan ahead with the right strategies and implement the right tools, the waves of vulnerabilities should be easily manageable.
