This talk walks through mechanisms used by container solutions to create an "isolated" computation environment and the weaknesses of each mechanism. It also covers a basic testing methodology that can be used when assessing a new container environment and the release of a new tool to assist in such an assessment.
Containerization is often used as a replacement for virtual machines to isolate customer data and customer code due to its ease of deployment and marginal performance impact. As security consultants, we have conducted numerous security reviews of a variety of container configurations, where real companies have been using Docker to securely run untrusted customer code.
While Docker is easy to get up and running, it is not always clear that certain high level settings have low level security implications. When configured poorly, a container running malicious code can view network traffic from the host or other co-located containers, access firewalled servers, affect the performance of other containers, or even run code on the host.
In this presentation, we’ll give insight into how Docker utilizes Linux kernel security features, such as capabilities and namespaces, in order to attempt to provide container isolation. We’ll illustrate common security pitfalls in container configurations and how to exploit them.
We’ll conclude with a demo of a new container auditing tool that finds common container configuration issues and presents exploits for these issues, if applicable. This tool may be leveraged by penetration testers assessing a container environment or by security engineers and developers aiming to ensure they’ve properly hardened their use of containers.