If you’ve been putting off addressing container security, today might be the day to make it a priority. In the last 24 hours, a critical vulnerability was reported that affects runc. Don’t be surprised if you’ve never heard of it. It’s the runtime that supports Docker, Kubernetes (k8s) and many other related services. While the vulnerability impact is quite severe (it allows container breakout), organizations with comprehensive cloud security programs inclusive of the Container Security Triad (see figure 1 below) will be well positioned.
Best practices mitigate
Container breakout has long been a concern of many security teams. However, in the case of this specific vulnerability, the risks can be mitigated by following best practices such as the Center for Internet Security’s (CIS) benchmarks for Docker and k8s (see sections 4.1 and 1.7.2 respectively). What makes this vulnerability unique is that only containers running as “root” (i.e. privileged containers) are impacted. Following the Container Security Triad, strong deploy security, where compliance to standards such as those created by CIS would be checked, certainly would have mitigated this vulnerability and ones like it in the future. Unfortunately, many popular images on DockerHub registry do not specify a non-root user. This makes the Docker engine run those containers as root by default. Running containers as non-root typically requires extra steps that many Docker image authors do not take. This highlights build security and the need for one or more trusted container registries in your organization. Trusted registries allow security teams to scan images (often pulled from DockerHub) for vulnerabilities and malware prior to deployment.
Figure 1: Container Security Triad
Compounding containers running as root is that many times developers “extend” existing Docker images to benefit from third-party libraries. Docker image poisoning is not a well-known attack but it is only a matter of time before we see more malicious third party Docker images. In 2018, RedLock discovered a way to exploit such Docker usage. This is where the last area of the Container Security Triad kicks in, run time. Malicious Docker images can be spotted with both process and technologies that baseline both normal activities as well as when images deviate from their digitally signed predecessors.
Comprehensive cloud security always wins
Software vulnerabilities will always be with us. Organizations with comprehensive cloud security programs that are inclusive of the Container Security Triad will be well positioned to deal with these types of vulnerabilities in the future without bolting on yet another point security product. With over 80 billion container downloads from the DockerHub registry, security teams would be wise to make container security the top issue in your next staff meeting. Not to mention that the exploit code for this CVE will be released on February 18, 2019.
If you or your team would like hands-on experience hunting similar container vulnerabilities, Palo Alto Networks will be leading an intensive lab at RSA 2019 where attendees can hone their skills. Sign up today and reserve your spot!
Stay tuned for our next blog which will go deeper into the Cloud Security Triad.