Security Risks and Challenges—Security Threat Analysis
Security Threat Analysis
When we talk about security risks to containers, we mean security threats to hosts, to containers, and to the carried applications.
1 Container Escape Attack
Similar to virtual machine (VM) escape attacks, in a container escape attack, attackers exploit a vulnerability existing in virtualized software to gain access to a host through a container, in a bid to launch an attack against the host.
Specifically, some PoC tools, such as Shocker[i], can demonstrate how to escape from a Docker container to a host and read the file content of a directory on the host. The key of Shocker attacks lies in the call of the open_by_handle_at function. As specially mentioned in the Linux manual, the caller must have the CAP_DAC_READ_SEARCH capability to invoke open_by_handle_at. However, Docker 1.0 adopts the blacklist mechanism to manage capabilities and sets no limit for the CAP_DAC_READ_SEARCH capability, leading to container escape risks.
2 Container Network Attack
Currently, Docker provides three types of network drivers, namely, bridge network driver, MacVLAN driver, and overlay network driver. All of them are prone to security risks.
For the bridge network driver built in Docker, a bridge called docker0, which acts as a router and NAT, connects to all containers. This means that all traffic between containers should first go through the container host. If there is no firewall between containers, attackers could exploit private network internal to the host to have containers attack one another.
The MacVLAN driver is a lightweight network virtualization technique. The MacVLAN driver connects container interfaces directly to host interfaces. Compared with the bridge network driver, the MacVLAN driver ensures better isolation from the physical network. However, this type of network driver does not exercise permission control between containers on the same virtual network, so that attackers could easily gain access to containers and launch network attacks.
To address this issue, Docker provides fine-grained container permission control by introducing some extension plug-ins. For example, a network plug-in provides the network connection model between containers, a volume plug-in provides multi-host volume management for Docker, and a privilege-based plug-in provides access control.
The overlay network driver uses the VXLAN technique to form a new virtual network on basis of the underlay network between different hosts. Such network architecture is often used in distributed orchestration frameworks. Though the overlay network driver can build a distributed container cluster rapidly, it has its own disadvantages. The biggest disadvantage is that traffic on the VXLAN network is not encrypted, which allows attackers to steal or tamper with the transmitted content.
However, Docker users can choose to encrypt data when setting IPSec tunnel parameters to guarantee the security of the container network. In addition, like the bridge network driver and MacVLAN driver, connections between containers in the overlay network mode are not effectively controlled, which may cause ARP spoofing, sniffing, and broadcast storm attacks. Such risks are prevalent in container networks at present.
- Denial-of-Service (DoS) Attack
Since containers are technically implemented based on the host kernel and share host resources, they are more prone to container-targeting DoS attacks. For example, by default, each container is allowed to use all memory on the host. If a container accesses the host exclusively or consumes plenty of host resources, other containers on the host are likely to work improperly due to lack of resources.
DoS attacks can be launched against any resources, such as computing resources, storage resources, and network resources.
(1) Computing resources
The fork bomb[1], in the computing field, is a form of DoS attack against computing resources. Normally, the host kernel only supports a specified number of processes. If too many processes are created in a container and they consume all process resources on the host, other containers will have no resources for creating new processes or the host may fail to work properly.
The fork bomb has always been a topic discussed in the Docker community ever since 2015. So far, the best way to defend against it is to restrict memory use (–kernel-memory=#M). However, errors may occur when this method is used for encrypted files.
(2) Storage resources
In the implementation of the container technology, file systems are isolated by applying mount namespaces. However, file system isolation is only a very basic requirement. It is recommended that AUFS not be used as the storage driver. This is because though it can create isolated container file systems, it has no limitations on storage space. In other words, if a container keeps writing files, it will finally fill up the storage media, leaving no space for other containers to perform write operations, and thereby causing a denial of service.
(3) Network resources
DoS attacks emerge in an endless stream, and network bandwidth exhaustion in a container is one type of such attacks. Specifically, an attacker directs a large number of controlled hosts to send loads of network packets to the attack target (a container), in a bid to take up its network bandwidth and consume the container host’s capability of processing network packets, finally causing a denial of service.
(To be continued)
[1] The fork bomb is a DoS attack that uses the fork system call (or other equivalent methods). Unlike viruses and worms, the fork bomb is not infectious. It disables systems that have restrictions on the number of concurrent processes and programs from executing new programs and makes systems that do not have such restrictions stop responding.
[i] Shocker https://github.com/gabrtv/shocker
