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]，包括安全漏洞認定範圍，上報方法(郵件報告給[email protected])，漏洞處理流程等；