docker security talks

Posted by deaguero at 2020-03-31

Recently, in terms of docker security information, according to the official docker security non events of docker, most of the vulnerabilities are system call functions such as keyctl(), ptrace(), and some are Linux kernel vulnerabilities, such as last year's dirtycow, which has a great impact. Because the container and the host share the same kernel, if the host's kernel is not upgraded, you can get the host permission by directly clicking expand in the container.

keyctl() ptrace() DirtyCow

According to the article "dirty cow - (cve-2016-5195) - docker container escape", the effect is good:

However, CAAS service providers such as AWS, gke and aliyun must have upgraded the system kernel for a long time, and cloud platforms generally run docker on KVM, so even if they escape from docker, they have to escape from virtual machines to reach the real server. In this respect, 360's tycoons have already introduced (escape from the docker KVM QEMU machine), although I can't understand


In the previous article, we discussed some methods to attack docker choreography and management system, mainly unauthorized access. When I tested, I found that there was no way to mount the host directory in the mesos document. In fact, it needed to be mounted by marathon when creating the container. At that time, I gave up without further study.

Mesos Marathon

When I read the document, I found that there is an interesting option privileged. Referring to the discussion of privileged containers and security, this option is used to facilitate the container to access the devices attached by the host, and at the same time, it gives the container some other capabilities (which are more are not clear).


This option was originally designed to run the container of docker in docker and build a continuous integration environment. But later, the original author also felt that this option was not safe, and wrote an article using docker in docker for your CI or testing environment? Think twice.

Docker in Docker

Why is privileged unsafe? See an example of using UNIX socket to pass file descriptors and finally read other user files (flags): 32c3 CTF: docker writeup. In this example, because the docker container specifies -- net = host at runtime, the network resources of the host can be accessed in the container. Since privileged will give all the capabilities to the container, adding -- privileged to docker run may cause more hidden dangers.

privileged Unix socket --net=host privileged Capabilities docker run --privileged

As mentioned earlier, privileged allows the container to access the devices mounted on the host. Refer to privileged docker containers, and let's see the differences in the / dev directory before and after using privileged:

privileged /dev

It is obvious that the root file system sda1 of the host can also be accessed. As for the utilization mode, we won't go into details.


In addition, I saw an interesting article, capturing all the flags in bsidessf CTF by pwning our infrastructure. We have heard that the organizer's competition platform was lost when playing CTF, but it's amazing that kubernetes was used in gke.

Originally, kubernetes had a thing called service account. For reference, use service account to access API server in kubernetes pod. This service account is for internal pods to access API. To quote from kubernetes' technical analysis of security:

Service Account Pods

The concept of service account is introduced based on the usage scenario that processes running in pod need to call kubernetes API and other services (such as image repository / file in NFS volumes mounted on POD). We use the service account to provide the ID for the pod. Service account and user account may cause confusion to some extent. User account can be considered as an individual interacting with kubernetes, usually as a human. Currently, it does not appear as a type in a code alone. For example, the users configured in Section 1 have the following differences:

Kubernetes will mount / run / secrets / to each pod by default, but this will cause attackers to enter the container and read the token to communicate with kubernetes API. For the detailed attack process, see

/run/secrets/ token

Kubernetes version 1.6 adds RBAC authentication to solve this problem, but I personally think it has little impact on the cloud platform based on kubernetes, because the service account only affects pods under the same namespace, and the namespaces among tenants must be different. In addition, some cloud platforms have been tested and found that instead of using service account, they obtain token through keystone API.

RBAC keystone

At last, the article mentions that cloud platforms such as gke and AWS will provide metadata services locally for developers to obtain authentication information of their own private warehouse. For example, if you execute curl on gke's machine, you can get token to access their own docker warehouse. Once it appears, you can get token to access their own docker warehouse SSRF, the attacker can steal the image from your private image source (of course, you need to find a way to know the project name and image name).

curl SSRF