Finding and fixing vulnerabilities is a good thing, according to Docker engineer Michael Crosby. In a standing-room only session at the DockerCon conference in Austin, Texas last week, Crosby went into detail on how the open-source container project deals with vulnerabilities.
CVE, which is an acronym for Common Vulnerabilities and Exposures, is a common nomenclature and numbering system for uniquely identifying a specific vulnerability. Crosby emphasized that CVEs are part of the software development lifecycle and CVEs ultimately serve to help make software more secure (when patched).
“The only reason why a project would have no CVEs is because no one cares enough to attack it,” Crosby said.
Docker, which is a four year-old open source application container project, has had its fair share of CVEs, and Crosby noted that each new discovery has helped to make the entire platform stronger.
Docker’s process for handling CVEs is fairly straightforward and includes seven simple steps.
- Receive report
- Verify finding
- Fix vuln
- Issue a new CVE number
- Send fix to downstreams (distros, clouds, select groups of users).
- After patch approval, 1 week embargo
- Public release.
“Security is a process, it’s not a sprint,” Crosby said. “It’s something that happens over years as you keep adding security features and new vulnerabilities keep posing up.”
Among the security issues that Crosby has dealt with at Docker is CVE-2016-8649 in November 2016. With that issue, a security vulnerability was discovered in LXC (Linux Containers), which at that point was not the base for Docker. Docker originally was based on LXC, but moved to its own libcontainer library. As it turns out though, the CVE-2016-8649 issue still impacted Docker and libcontainer, potentially enabling an attacker to attack a host operating system.
Crosby explained how Docker worked the problem, eventually discovering the root cause (and a few other issues along the way) that ended up being patched in the mainline Linux 4.10 kernel in early 2017.
While CVE-2016-8649 and other vulnerabilities outlined by Crosby did represent a potential risk to Docker users, there also is a simple mitigation – don’t run Docker container as root.
“Running as non-root in a container is immensely more secure,” Crosby said.
Sean Michael Kerner is a senior editor at eSecurityPlanet and InternetNews.com. Follow him on Twitter @TechJournalist.