AI繁榮下的隱憂——Google Tensorflow安全風險剖析

本文由雲+社區發表

做者：[ Tencent Blade Team ] Cradmin

咱們身處一個鉅變的時代，各類新技術層出不窮，人工智能做爲一個誕生於上世紀50年代的概念，近兩年出現井噴式發展，獲得各行各業的追捧，這背後來自於各類力量的推進，諸如深度學習算法的突破、硬件計算能力的提高、不斷增加的大數據分析需求等。從2017年的迅猛發展，到2018年的持續火爆，國內外各個巨頭公司如騰訊、阿里、百度、Google、微軟、Facebook等均開始在人工智能領域投下重兵，毫無疑問，這一技術將來將會深度參與咱們的生活並讓咱們的生活產生巨大改變：人工智能時代來了！

面對一項新技術/新趨勢的發展，做爲安全研究人員該關注到什麼？沒錯，每個新技術的誕生及應用都會伴隨有安全風險，安全研究人員要在風暴來臨以前作到未雨綢繆。

Blade Team做爲關注行業前瞻安全問題的研究團隊，天然要對AI技術進行安全預研。

一個典型的人工智能系統大體由3部分組成：算法模型，AI支撐系統(訓練/運行算法的軟件基礎設施)和業務邏輯及系統。好比一我的臉識別系統基本架構以下：

圖1：典型人臉識別系統架構

從安全視角來看，咱們能夠得出3個潛在的攻擊面：

AI算法安全：算法模型是一個AI系統的核心，也是目前AI安全攻防對抗的焦點。具體來說，目前AI算法安全的主要風險在於對抗樣本(adversarial examples)攻擊，即經過輸入惡意樣原本欺騙AI算法，最終使AI系統輸出非預期的結果，目前已發展出諸如生成對抗網絡(GAN)這種技術[0]，以AI對抗AI，在這個領域學術界和工業界已有大量研究成果，你們可Google瞭解。

AI支撐系統安全：AI算法模型的運行和訓練都須要一套軟件系統來支撐，爲了提升計算效率和下降門檻，各大廠商開發了機器學習框架，本文的主角Google Tensorflow就屬於這一層，類比於計算機系統中的OS層，能夠想象到這裏若是出現安全問題，影響如何？而這類框架的安全性目前並無獲得足夠的關注。

業務邏輯系統：上層業務邏輯及相關係統，與傳統業務和運維安全風險差異不大，再也不贅述。

通過近幾年的發展，各類機器學習框架不斷涌現出來，各有特點，其中不乏大廠的身影，咱們選取了三款使用量較大的框架做爲研究對象：

Tensorflow[1]：由Google開發，面向開源社區，功能強大，易用性高，早期性能稍差，但在Google強大的工程能力下，已有明顯改觀，從使用量上看，目前是機器學習框架裏面的TOP 1。

Caffe[2]：2013年由UC Berkely的賈揚清博士開發，在學術界使用極其普遍，卷積神經網絡的實現簡潔高效，但因歷史架構問題，不夠靈活。目前賈教主已就任Facebook，並在Facebook的大力支持下，推出了Caffe2，解決Caffe時代留下的問題（編輯注：發佈本文時，已有消息稱賈教主已經加盟阿里硅谷研究院，可見巨頭對AI人才的渴求）。

Torch[3]：Facebook內部普遍使用的一款機器學習框架，靈活性和速度都不錯，惟一不足是默認採用Lua語言做爲API接口，初學者會有些不習慣，固然目前也支持了Python。

圖2 業界流行機器學習框架簡要對比

以Tensorflow爲例，咱們先來看一下它的基本架構：

圖3 Tensorflow基本架構[4]

由上圖大體能夠看出，除了核心的機器學習算法邏輯外(Kernel implementations)，Tensorflow還有大量的支撐配套系統，這無疑增長了軟件系統的複雜性。

咱們繼續沿用上一節的思路，首先詳細分析下Tensorflow的攻擊面。這裏也插個題外話，分享下我的的一些研究習慣，通常在接觸到一個新領域，筆者習慣通讀大量資料，對該領域的基本原理和架構有個相對深刻的瞭解，必要時結合代碼粗讀，對目標系統進行詳細的攻擊面分析，肯定從哪一個薄弱點入手，而後纔是看我的喜愛進行代碼審計或Fuzzing，發現安全漏洞。在筆者看來，安全研究前期的調研工做必不可少，一方面幫你肯定相對正確的研究目標，不走過多彎路，另外一方面對功能和原理的深刻理解，有助於找到一些更深層次的安全問題。

經過對Tensorflow功能和架構的瞭解，筆者大體把攻擊面分爲如下幾類：

*輸入文件解析邏輯：包括對訓練和推斷時用到的圖片、視頻、音頻等類型文件的解析處理*

*模型處理邏輯：模型文件的解析和模型運行機制*

*機器學習算法邏輯：機器學習算法實現邏輯*

*分佈式部署及擴展功能：包括Tensorflow分佈式集羣功能，性能優化XLA Compiler，自定義函數擴展功能等。*

詳細可參考下圖，這是當時基於Tensorflow 1.4版本的分析，有興趣的讀者能夠自行分析添加。在隨後的審計中，咱們在多個攻擊面中發現了安全問題，其中一個最嚴重的風險存在於Tensorflow的模型處理機制。

圖4 Tensorflow攻擊面分析

咱們先來了解下Tensorflow的模型機制。

顧名思義，Tensor是Tensorflow中的基本數據類型(或者說數據容器)，flow表示dataflow，Tensorflow用數據流圖(dataflow graph)來表示一個計算模型，圖中的結點(node)表示計算操做(operation)，圖中的邊(edge)表示數據輸入和輸出，當咱們設計了一個機器學習模型，在Tensorflow中會以一張數據流圖來表示，最終算法模型會以圖的形式在Tensorflow運行時(runtime)下執行，完成咱們須要的運算。能夠參考Tensorflow官網的一個示例。

圖5 Tensorflow的數據流圖[5]

機器學習模型訓練中常常會出現這樣的場景：

1) 須要中斷當前訓練過程，保存模型，以備下次從中斷處繼續訓練

2) 把訓練好的模型保存，分享給他人進一步調優或直接使用

Tensorflow提供了兩種種模型持久化機制，能夠把算法模型保存爲文件：tf.train.Saver和tf.saved_model。兩組API在把模型持久化爲文件時，結構上有些差別，tf.train.Saver適合臨時保存被中斷的訓練模型，被保存的模型稱爲一個checkpoint，tf.saved_model更適合保存完整的模型提供在線服務。

tf.train.Saver保存的模型文件以下：

savermodel.meta是模型的元數據，也就是數據流圖的描述文件，採用特定的二進制格式，savermodel.data-xxx保存着模型中各個變量的值。

再來看下tf.saved_model保存的模型文件：

saved_model.pbtxt保存着表示算法模型的圖結構，能夠指定保存爲protobuf文本格式或二進制格式，但一般狀況下出於空間效率考慮，默認採用二進制形式保存，variables目錄中保存模型中變量的值。

能夠看到，無論哪一種方式，都須要保存關鍵的數據流圖的結構，打開saved_model.pbtxt，仔細看下咱們關心的數據流圖：

能夠比較直觀的看到圖的結構，好比Add是操做類型，輸入是參數x和y，輸出是z，不可貴出是一個簡單的加法計算z=x+y；Tensorflow API提供了大量的操做類型，來知足各類計算需求。

圖6 Tensorflow Python API[6]

看到這裏，你們可有什麼想法？沒錯，既然算法模型是以圖的形式在Tensorflow中執行，從圖的角度看，咱們可否在不影響圖的正常流程的狀況下，插入一些額外的操做(結點)呢？進一步，若是這些操做是惡意的呢？

從上一節的分析，咱們發現了一個讓人略感興奮的攻擊思路，在一個正常的Tensorflow模型文件中插入可控的惡意操做，如何作到呢？須要知足兩個條件：

1）在數據流圖中插入惡意操做後，不影響模型的正常功能，也就是說模型的使用者從黑盒角度是沒有感知的；

2）插入的操做可以完成「有害」動做，如代碼執行等。

先看下第二個條件，最直接的「有害」動做，通常可關注執行命令或文件操做類等，而Tensorflow也確實提供了功能強大的本地操做API，諸如tf.read_file, tf.write_file, tf.load_op_library, tf.load_library等。看這幾個API名字大概就知其義，最終咱們選擇使用前2個讀寫文件的API來完成PoC，其餘API的想象空間讀者可自行發掘。在驗證過程當中，筆者發現這裏其實有個限制，只能尋找Tensorflow內置的API操做，也叫作kernel ops，若是是外部python庫實現的API函數，是不會插入到最終的圖模型中，也就沒法用於這個攻擊場景。

知足第一個條件，並無想象的那麼簡單，筆者當時也頗費了一翻周折。

咱們以一個簡單的線性迴歸模型y=x+1爲例，x爲輸入變量，y爲輸出結果，用Tensorflow的python API實現以下：

讀寫文件類的操做顯然與線性迴歸計算無關，不能直接做爲模型的輸入或輸出依賴來執行；若是直接執行這個操做呢？

圖7 tf.write_file API文檔[7]

從tf.write_file API文檔能夠看到，返回值是一個operation，能夠被Tensorflow直接執行，但問題是這個執行如何被觸發呢？在Tensorflow中模型的執行以run一個session開始，這裏當用戶正常使用線性迴歸模型時，session.run(y)便可獲得y的結果，若是要執行寫文件的動做，那就要用戶去執行相似session.run(tf.write_file)這樣的操做，顯然不正常。

在幾乎翻遍了Tensorflow的API文檔後，筆者找到了這樣一個特性：

圖8 tf.control_dependencies API文檔[8]

簡單來講，要執行control_dependencies這個context中的操做，必需要先計算control_inputs裏面的操做，慢着，這種依賴性不正是咱們想要的麼？來看看這段python代碼：

這個success_write函數返回了一個常量1，但在control_dependencies的影響下，返回1以前必須先執行tf.write_file操做！這個常量1正好做爲模型y=x+1的輸入，漏洞利用的第一個條件也知足了。

最後還有一個小問題，完成臨門一腳，可以讀寫本地文件了，能幹什麼「壞事」呢？在Linux下能夠在crontab中寫入後門自動執行，不過可能權限不夠，筆者這裏用了另一種思路，在Linux下讀取當前用戶home目錄，而後在bashrc文件中寫入反連後門，等用戶下次啓動shell時自動執行後門，固然還有其餘利用思路，就留給讀者來思考了。值得注意的是，利用代碼中這些操做都須要用Tensorflow內置的API來完成，否則不會插入到圖模型中。

把上面的動做串起來，關鍵的PoC代碼以下：

當用戶使用這個訓練好的線性迴歸模型時，通常使用如下代碼：

運行效果以下：

模型使用者獲得了線性迴歸預期的結果4（x=3, y=4），一切正常，但其實嵌入在模型中的反連後門已悄然執行，被攻擊者成功控制了電腦。

圖9 Tensorflow模型中反連後門被執行

在完成這個PoC後，咱們仔細思考下利用場景，在Tensorflow中共享訓練好的機器學習模型給他人使用是很是常見的方式，Tensorflow官方也在GitHub上提供了大量的模型供研究人員使用[9]，咱們設想了這樣一個大規模攻擊場景，在GitHub上公佈一些經常使用的機器學習模型，在模型中插入後門代碼，而後靜待結果。

回顧一下，這個安全問題產生的根本緣由在於Tensorflow環境中模型是一個具備可執行屬性的載體，而Tensorflow對其中的敏感操做又沒有作任何限制；同時在通常用戶甚至AI研究人員的認知中，模型文件是被視做不具備執行屬性的數據文件，更增強了這種攻擊的隱蔽性。

咱們把這個問題報告給Google後，通過多輪溝通，Google Tensorflow團隊最終不認爲該問題是安全漏洞，但認爲是個高危安全風險，並專門發佈了一篇關於Tensorflow安全的文章[10]，理由大體是Tensorflow模型應該被視做可執行程序，用戶有責任知道執行不明模型的風險，並給出了相應的安全建議。

在對Tensorflow其餘攻擊面的分析中，咱們嘗試了人工審計代碼和Fuzzing的方法，又發現了多個安全漏洞，大部分屬於傳統的內存破壞型漏洞，涉及Tensorflow的圖片解析處理、模型文件解析、XLA compiler等功能，而且漏洞代碼都屬於Tensorflow框架自己，也從側面反映了Tensorflow在代碼安全上並無作更多的工做。

下面是Tensorflow發佈的安全公告及致謝[11]，目前爲止共7個安全漏洞，均爲Tencent Blade Team發現，其中5個爲筆者發現。

在研究過程當中，咱們也注意到業界的一些相似研究，如360安全團隊對多款機器學習框架用到的第三方庫進行了安全審計，發現存在大量安全問題[12]，其中多爲傳統二進制漏洞類型。

回顧整個漏洞報告和處理流程，可謂一波三折。最初上報漏洞時，咱們發現除了GitHub上的issue，Tensorflow彷佛沒有其餘的漏洞上報渠道，出於風險考慮，咱們以爲發現的安全問題在修復以前不適合在GitHub上直接公開，最後在Google Groups發帖詢問，有一個自稱是Tensorflow開發負責人的老外回覆，能夠把安全問題單發給他，開始筆者還懷疑老外是否是騙子，過後證實這我的確實是Tensorflow團隊開發負責人。

通過持續近5個月、幾十封郵件的溝通，除了漏洞修復以外，最終咱們也推進Google Tensorflow團隊創建了基本的漏洞響應和處理流程。

1）Tensorflow在GitHub上就安全問題做了特別說明Using Tensorflow Securely[10]，包括安全漏洞認定範圍，上報方法(郵件報告給security@tensorflow.org)，漏洞處理流程等；

圖10 Tensorflow安全漏洞處理流程

2）發佈安全公告，包括漏洞詳情和致謝信息[11]；

3）在Tensoflow官網(tensorflow.org)增長一項內容Security[13]，並連接至GitHub安全公告，引導用戶對安全問題的重視。

針對咱們發現的模型機制安全風險，Google在Using Tensorflow Securely這篇安全公告中作了專門說明[10]，給出了相應的安全措施：

1）提升用戶安全意識，把Tensorflow模型視做可執行程序，這裏實際上是一個用戶觀念的轉變；

2）建議用戶在沙箱環境中執行外部不可信的模型文件，如nsjail沙箱；

3）在咱們的建議下，Tensorflow在一個模型命令行工具中增長了掃描功能（tensorflow/python/tools/saved_model_cli.py），能夠列出模型中的可疑操做，供用戶判斷。

能夠看出，Tensorflow團隊認爲這個安全風險的解決主要在用戶，而不是Tensorflow框架自己。咱們也在Blade Team的官方網站上對這個風險進行了安全預警，並命名爲「Columbus」[14]。

上文提到的其餘內存破壞型漏洞，Tensorflow已在後續版本中修復，可參考安全公告[11]。

AI安全將走向何方？咱們相信AI算法安全的對抗將會持續升級，同時做爲背後生產力主角的基礎設施軟件安全理應受到應有的關注，筆者但願這個小小的研究能拋磚引玉（實際上咱們的研究結果也引發了一些專家和媒體的關注），期待更多安全研究者投身於此，一塊兒爲更安全的將來努力。

[0] https://en.wikipedia.org/wiki/Generative_adversarial_network

[1] https://www.tensorflow.org/

[2] http://caffe.berkeleyvision.org/

[3] http://torch.ch/

[4] https://www.tensorflow.org/guide/extend/architecture

[5] https://www.tensorflow.org/guide/graphs

[6] https://www.tensorflow.org/versions/r1.12/api_docs/python/tf

[7] https://www.tensorflow.org/versions/r1.12/api_docs/python/tf/io/write_file

[8] https://www.tensorflow.org/versions/r1.12/api_docs/python/tf/control_dependencies

[9] https://github.com/tensorflow/models

[10] https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md

[11] https://github.com/tensorflow/tensorflow/blob/master/tensorflow/security/index.md

[12] https://arxiv.org/pdf/1711.11008.pdf

[13] https://www.tensorflow.org/community#security

[14] https://blade.tencent.com/columbus/

此文已由騰訊雲+社區在各渠道發佈

獲取更多新鮮技術乾貨，能夠關注咱們騰訊雲技術社區-雲加社區官方號及知乎機構號