Since Docker’s release in 2013, several vulnerabilities have been discovered that could lead to privilege escalation and arbitrary code execution. In our Docker Security and Containerization Report, we review and highlight the top 5 vulnerabilities from high to critical severity.
Container Security and Risks
Based on interviews with developers who use Docker in their software deployment process, and the vulnerabilities discussed in our Docker security report (bypasses, privilege escalation, denial of service, and code execution), summarized below are the top 5 risks inherent across container deployment and maintenance in an organization’s IT environment.
1. UNSECURED COMMUNICATION AND UNRESTRICTED NETWORK TRAFFIC
By default, in some versions of Docker, all network traffic is allowed between containers on the same host. This increases the risk of unintended and unwanted disclosure of information to other containers. Developers should only allow intercommunication that is necessary by linking specific containers. This will significantly reduce attack surfaces by restricting container access.
To protect the confidentiality and integrity of all network traffic, communications with Docker registries should be encrypted through TLS security protocol.
Organizations should evaluate the effectiveness of their current controls and implement Docker-specific controls to mitigate risks that may impact business objectives. In general, practicing good cyber hygiene and increasing transparency of the software development process in Docker will reduce the risk significantly.
2. UNRESTRICTED ACCESS TO PROCESS AND FILES
An attacker who gains access to one container may have the capability to gain access to other containers or the host. For example, a container may have the ability to access the system file directory on the host via remounting, which is critical to security enforcement.
If the attacker has root access to the container, he or she may have the ability to gain root access to the host, often through bugs in the application code. The access control best practice recommendations include the principle of least privilege. The user namespace feature in Linux containers will allow developers to avoid root access by giving isolated containers separate user accounts, and mandate resource constraints, so users from one container do not have the capability to access other containers or exhaust all resources on the host.
However, this feature is not enabled by default. System administrators should have this feature enabled to leverage application sandboxing in Docker.
3. KERNEL-LEVEL THREATS
Docker is designed to have all containers share the same kernel and the host. This provides convenience but also amplifies the impact of any vulnerabilities present in the kernel. System administrators should ensure that the host environment is properly hardened and patched to reduce the likelihood of privilege escalation, arbitrary code execution, and denial of services.
They should also restrict applications that run on privileged ports besides the ones that are necessary (e.g. Apache server) since those ports have more access to the kernel.
4. INCONSISTENT UPDATE AND PATCHING OF DOCKER CONTAINERS
Running an older version of Docker containers can expose internal IT environments to higher risks of a breach, and potential loss of sensitive information.
New security features and bug fixes are often included in the update packages. Like any technology we run in the IT environment, a patching policy should be in place and enforced.
5. UNVERIFIED DOCKER IMAGES
Developers need to make sure they are downloading Docker images from trusted sources that are curated by the Docker community or the vendor and run vulnerability scans against those images before running them in the host environment.
To ensure the integrity of a container image, content trust should be enabled to allow digital signatures for data sent to and received from remote Docker registries.
Learn more about Docker Security and Containerization. Download our free report today.
August 24, 2017