面向云計算平臺的虛擬機同駐方法

劉維杰，王麗娜，王丹磊，尹正光，付楠

?

面向云計算平臺的虛擬機同駐方法

劉維杰1,2，王麗娜1,2，王丹磊1,2，尹正光3，付楠1,2

（1. 空天信息安全與可信計算教育部重點實驗室，湖北 武漢 430079；2. 武漢大學國家網絡安全學院，湖北 武漢 430079；3. 阿里云計算有限公司，浙江 杭州 311121）

若攻擊者想攻擊云平臺上某一目標虛擬機，則其必須與目標虛擬機同駐。基于此，提出一種虛擬機同駐方法，通過構建云環境中自適應的隱蔽信道，結合基于隱蔽信道的虛擬機同駐檢測方法和自動化虛擬機洪泛策略，并在國內某知名商業云平臺上進行同駐驗證。實驗表明，所構建的自適應隱蔽信道傳輸正確率可高達95%以上；所提出的同駐檢測方法置信度高，誤檢率不超過5‰。同駐方法不會破壞云平臺本身隔離性且具有一定的通用性，但潛在威脅極大，亟需重視與防范。

云計算平臺；虛擬機同駐；隱蔽信道；虛擬機洪泛

1 引言

云計算的概念從提出到廣泛應用，在短短幾年的時間里經歷了巨大的變革。目前，國內外的商用云計算業務都已進入蓬勃發展的重要時期，云計算也越來越多地被視為存儲數據和部署服務的下一代IT基礎設施。然而，多租戶動態聚合、邊界泛化的特點使云計算平臺難以抵抗虛擬機之間共享計算資源所帶來的安全威脅。其中，最主要的是虛擬機同駐威脅，即將屬于攻擊者的虛擬機實例運行在目標虛擬機所在的物理主機上。由于云環境“虛擬隔離、物理共存”的特點，云平臺允許同駐的虛擬機共享物理主機的大部分資源，因此同駐威脅難以避免，其主要包括資源干擾、拒絕服務、隱蔽/側信道、虛擬機跳躍、虛擬機逃逸和遷移間隙等[1-9]。惡意的虛擬機同駐會破壞云平臺中數據的機密性和資源的可用性，導致嚴重的安全問題，對大規模企業用戶和普通云租戶都會造成極大危害。

如果攻擊者意圖實施針對云計算平臺的攻擊，則必須先實現其惡意虛擬機與目標虛擬機的同駐。早在2009年，Ristenpart等[10]首次提出了Amazon EC2（elastic compute cloud）平臺上的虛擬機同駐方案，但是其檢測同駐的方法是基于兩臺虛擬機之間的網絡分組往返時延（RTT, round trip time）會隨同駐與否而發生變化的原理，該原理過于簡單，且未能考慮到云平臺中復雜的網絡環境所造成網絡分組時延測量不準確的問題。

在判斷虛擬機是否同駐方面，Bates等[11]提出利用“同駐水印”來進行同駐檢測。其原理為利用檢測虛擬機向外部周期性地發送網絡分組，同時通過外部代理向目標虛擬機發送網絡分組，通過測量網絡分組通信是否有足夠的時延來判斷虛擬機是否同駐。然而，此方法與Ristenpart等[10]提出的同駐檢測方法都依賴云平臺允許虛擬機自由地和外部進行網絡通信，很容易由于云平臺因安全考慮將ICMP（internet control message protocol）禁止而失效[12]，且云平臺一旦對不同的私有專用網進行隔離[13]，基于網絡信息的同駐方案將會變得毫無用武之地。

Zhang等[14]提出了一種虛擬機同駐探測方案，其讓租戶將一些暫不使用的處理器緩存行留為警報行，若探測到警報行被使用或其負載與之前不同，則表明其他虛擬機使用了該處理器緩存（下文簡稱cache）區域，同駐檢測器進程就會發出報警。同時，余思等[15]將虛擬機同駐檢測問題具體化為cache負載的差異性度量，基于cache負載特征匹配來推斷目標虛擬機與攻擊者虛擬機是否同駐。這兩種方案都根據cache的負載差異進行同駐判斷，但是云平臺為了降低能耗，提高資源利用率，引入了各種基于硬件特性的資源優化機制和資源隔離機制[16]，使cache的負載測量并不準確，并且計算cache負載特征方法復雜，很難保證同駐檢測的實時性。

基于隱蔽信道的同駐檢測方案效果好，但難以在此基礎上實現虛擬機同駐[17]。針對這一問題，本文以“先假設，后驗證”的思路，提出了一種面向云計算平臺的虛擬機同駐方案，如圖1所示。攻擊者在實施同駐的過程中，需要對同駐情況進行判定，因此需要準確率高的虛擬機同駐檢測手段來確定同駐情況。在攻擊者有目的性地進行虛擬機洪泛后，還需借助合謀方案對目標虛擬機進行精確定位。

本文方案充分考慮具體的云計算環境，力求同駐檢測正確率高且易于部署。該方案改進了現有的兩種隱蔽信道，并將其運用到虛擬機的同駐檢測方案中，打破了基于隱蔽信道的檢測方案在現實環境難以實現同駐的壁壘；提出了一種基于后驗概率的自動化虛擬機洪泛方法，有針對性地確定目標虛擬機與洪泛虛擬機的同駐。利用本方案在國內某知名商用云平臺上進行實際驗證，對增強現有商用云平臺的安全性有重要意義。

2 云計算環境下同駐威脅模型

在公有云環境中，攻擊者理論上可以通過合法渠道獲得部分資源，即攻擊者能夠創建任意的虛擬機并對其進行管理。本文基于該事實提出如下假設。

假設1 云平臺系統有良好的隔離性，云平臺管理系統和其上的客戶操作系統均是干凈且安全的（及時更新，補丁完備），同時云管理員的操作均是善意且合規的，不存在內部威脅[18]。如此，本文中的攻擊者僅通過側信道的方式實現與目標虛擬機同駐。

假設2 云平臺的各個租戶之間是互不信任的，且不具有任何特殊權限。攻擊者只能期望利用側信道攻擊來獲取其他用戶的隱私信息[19]。攻擊者的目標為使用云平臺的正常租戶，他們利用虛擬機運行某些機密性的相關應用。

假設3 攻擊者有足夠的資金保證其能夠開啟足夠多的虛擬機，同時還能夠通過社會工程的方式獲取目標開啟虛擬機的準確時間[11]。

上述假設均符合實際應用場景，假設2中針對攻擊者背景知識的假設也具有相當的普適意義。為了方便描述，下面將攻擊者創建并擁有的虛擬機稱為攻擊虛擬機，將目標用戶創建并擁有的虛擬機稱為目標虛擬機。

3 基于隱蔽信道的虛擬機同駐檢測

如果攻擊者意圖實現與目標虛擬機同駐，則必須擁有檢測攻擊虛擬機是否與目標虛擬機同駐的能力。于是，在描述同駐方案前，本節提出其實現的基礎——基于隱蔽信道的同駐檢測方案。

現有研究中，基于網絡信息的同駐檢測方法實現簡單，檢測效率較高，但是檢測準確率低，只能作為其他同駐檢測方法的輔助手段使用；基于資源干擾的同駐檢測方法雖然實現復雜，但檢測準確率較高，適用范圍廣。但是，隨著虛擬機資源管理機制的優化以及硬件技術的不斷發展，同駐虛擬機之間的相互干擾越來越難被發現[17]。基于硬件的隱蔽信道作為云平臺中不可避免地存在，可被充分地應用于同駐檢測中[21]。

因此，本文以準確性、高效性和實用性為目標，提出基于隱蔽信道的同駐檢測方案，并以基于內存總線沖突的隱蔽信道和基于最高級緩存（LLC, last level cache）的隱蔽信道為例，實現了這兩種同駐檢測方案。由于該方案以云平臺中的共享硬件資源為渠道構建，因此具備極強的通用性[17]。

3.1 云環境下隱蔽信道機理與構建

基于微處理器架構的隱蔽信道是多用戶計算機系統中最常見的隱蔽信道類型，其主要存在于具有共享資源的系統中，如云計算環境中。不過在嘈雜的公有云環境中，微處理器架構隱蔽信道會面臨更多的問題。虛擬機遷移、vCPU調度以及Hypervisor的活動增加了許多噪聲，這些都給隱蔽信道精確同步帶來了挑戰。

圖2 內存與新型LLC的映射索引

3.1.1 基于LLC的隱蔽信道

與其他隱蔽信道介質相比，cache對于攻擊者更具吸引力。因為cache的高操作速度可產生高帶寬，并且不受軟件系統限制，可以繞過許多高級隔離機制，所以近年來基于cache的隱蔽信道備受重視[20-21]。其中，最常用的交替通信技術是Prime + Probe方法[22]和Flush + Reload[23]方法。

文獻[24-25]提出了如何對該散列函數進行逆向，但這種逆向工程需要進行大量的實驗，消耗大量時間。于是，文獻[7]提出了一種通過構建沖突集的方法來尋找能夠映射到相同cache set而虛擬地址不同的內存塊。本文對這種方法進行了改進，提出了一種快速構建沖突內存塊的方法，能夠進一步地縮短尋找時間。改進的方法描述如算法1所示。其中，函數()為所定義的Probe訪存原語。

算法1 基于LLC的隱蔽信道沖突集構建算法

輸入 候選內存行lines

輸出 驅逐集，每個分片一個驅逐集

(；)

讀取；

for eachin set do

讀取；

end for

end function

構建

隨機化；

for each∈do

if not(_；)

將放入；

end for

構建

for eachindo

if(，)

for eachindo

if not(_；)

將放入；

end for

if∪≠?

=e∪

輸出；

；

end for

通過將具有同樣元素的驅逐集合并，使本文構建驅逐集的方案更加圓滿，能夠在每個slice對應的驅逐集中找到超過組相聯路數的可供驅逐的內存行。這樣，在隱蔽信道構建時，就可以更加靈活地選用任意的slice ID和set ID作為LLC沖突集的ID。

3.1.2 基于內存總線的隱蔽信道

內存總線負責處理器與主存之間的數據傳輸，是現代計算機系統中不可或缺的組成部分。處理器內的CPU核心都共用該內存總線。因此，內存總線上的沖突將會導致系統范圍可觀測的內存訪問時延。因此，利用某些特定的程序行為所觸發的內存總線沖突就可以構建出一種隱蔽信道[26]。x86架構中，處理器利用總線鎖（memory bus lock）實現內存原子指令。對于未對齊的內存區域，執行內存原子指令會觸發內存總線鎖。利用這種機制，可以構建一種高速、可靠、跨虛擬機的隱蔽信道，如圖3所示。

圖3 基于內存總線的隱蔽信道

同樣地，對現有的基于內存總線的隱蔽信道進行了改進：當發送方使用特定的原子操作時，接收方使用SSE (streaming SIMD extension)指令集的某些訪存指令操作，避免訪問cache，使正常訪問內存總線時的訪存時間不會因cache命中而產生影響，從而保證每次正常訪存（總線不沖突）時的時間基本一致，進而保證了信道傳輸的準確性。具體如算法2所示。

算法2基于內存總線的隱蔽信道構建算法

：異常操作數原子指令

[]，[]：發送和接收數據

發送方：

for=1 to1 do

if[]=1

for=0 to1 do

M內存訪問；

end for

else

for=0 to1 do

SIMD內存訪問；

end for

end for

接收方：

for=1 to1 do

for=0 to1 do

SIMD內存訪問；

end for

if 平均訪問時間

[]=1；

else

[]=0；

end for

3.2 面向碼元識別的自適應信道優化

為了解決信道在嘈雜的公有云環境中傳輸正確率會受到影響的問題，本文引入了自適應的碼元識別技術，以此來提升傳輸正確率。

本文通過使用數據幀（frame）來加強通信協議對時鐘漂移和調度中斷的彈性。傳輸的數據被分成固定長度，發送方使用偽隨機數生成算法來產生每一個數據幀的載荷[27]，并用起始模式和停止模式將每個數據段構造成數據幀。這種方式具備兩個優點：①當發送方檢測到傳輸中斷時，不需要重傳全部數據，僅需重發相關數據幀；②在傳輸期間總是不可避免地會丟失部分數據，利用數據幀，接收方能更加容易地定位錯誤，進行糾錯處理。

3.2.1 信號的平滑與連續識別

由于嘈雜的云環境帶來的噪聲，信道若未經過去噪便進行碼元識別操作，將會引入相當大的傳輸錯誤。平滑濾波技術能夠過濾低頻信號中的噪聲，它不經由傅里葉轉換，在圖像處理領域被廣泛應用。本文利用平滑濾波來實現信號的初篩。

經過去噪操作后，所接收的“0”和“1”的區別已經較為明顯（在基于內存總線的信道中，發送“0”僅消耗約100個CPU時鐘周期，發送“1”需消耗幾千個CPU時鐘周期；在基于LLC的信道中，發送“0”消耗約30個CPU時鐘周期，而發送“1”需要消耗約100個時鐘周期）。因此，采取聚類的方式來區分接收的信息即可。在此情況中，僅需要將數據分為兩類，即僅需要求出聚類中心，之后再進行簡單判斷。由于不用考慮時間序列，需要聚類的數據僅為一維數據。在此本文采用最為簡單有效的均值聚類法來實現該功能。

3.2.2 信道自適應同步與校準

由于發送方和接收方分屬不同的虛擬機，它們之間的調度差異將導致數據傳輸和檢測過程不同步，進而對信道的調制造成很大的問題。本文通過自時鐘編碼克服時鐘失步，并使用差分曼徹斯特編碼傳輸數據位。更重要的是，當通信雙方傳輸起始時間不同時，有很大的概率導致傳輸的數據極不連續。同時，為了減少重發次數，節省時間開銷，必須確保發送方和接收方的時隙是對齊的。如果沒有對齊，兩者將在重疊的時間內爭用該信道并引入位翻轉錯誤。這種不受限制的爭用會導致“0”和“1”的值的可分離分布較少，加劇發送方和接收方的競爭，明顯降低信道的容量與可用性。針對這個問題，本文提出時鐘同步與接收確認機制來提高信道可靠性，如算法3所示。其中，()與()分別表示發送幀與接收幀的函數方法，()表示搜索并微調當前幀延時的函數方法。

算法3 自適應的信道同步算法

[]，[]：發送和接收數據

()：信道傳輸正確率計算函數

發送方：

for<1 to 20 do

([])；

=+1；/* 微調1 μs */

end for

確定；

接收方：

for<1 to 20 do

([])；

end for

=([])；

本文提出的同步協議能夠實現在幾百μs的時鐘差異內，實現高精度的對齊傳輸。通過在隱蔽通道上傳送一個已知的比特序列來進行多輪處理。在每次通信之后，發送方將其時鐘移動1 μs，稍微改變兩個進程的執行起始時間。隨著時鐘變得更加同步，兩個進程的爭用變得更加一致。一旦達到最高正確率后，發送方的每次移位都會降低信道的傳輸正確率。此時，接收方通過測量最高正確率便可能定位到最佳的移位大小。同步過程的耗時取決于用于測試的分組大小，基本上每個虛擬機只需要執行一次即可完成同步。

4 面向云平臺的虛擬機同駐方案

由于虛擬機同駐造成的危害越來越大，研究人員在云平臺的虛擬機投放策略上提出了抵御同駐危害的方法。已有研究[28-29]提出虛擬機動態部署算法，基于云提供商協助的VM遷移服務，通過不斷地重新部署VM，使任意兩臺VM間不存在足夠長的同駐時間，從而限制由側信道引發的信息泄露。上述方法雖然能夠在一定程度上抵御同駐威脅，但其防御窗口過長，仍無法從本質上防止虛擬機實例洪泛造成的同駐。

虛擬機實例洪泛，即攻擊者在同一時間、同一個云平臺可用區，開啟大量的虛擬機實例。這些實例可能是攻擊者利用自身賬號投放，也可能是通過其控制的虛擬機僵尸網絡投放。虛擬機實例洪泛本質上是對云平臺虛擬機分布策略的濫用，但其并不違反云平臺的商業策略和服務等級協議。

當攻擊者實例開啟時間接近受害者虛擬機實例開啟時間時，攻擊者可以有效地利用云平臺平行放置的部署算法來實現一定概率的攻擊者實例與受害者實例同駐。由于云計算的動態特性，服務器通常在實例上運行，不需要時終止，稍后再運行。例如，攻擊者可以監視服務器的狀態（如通過網絡探測）直到該實例消失，然后在發現一個新實例（該服務）重新開啟時進行實例洪泛。攻擊者甚至可以利用該特點主動觸發新的目標虛擬機實例。

4.1 基于后驗概率的虛擬機洪泛覆蓋

本節提出了一種基于后驗概率的自動化虛擬機方案。通過該方案可以得出：①被攻擊的虛擬機分布在各臺物理主機的概率；②本次投放VM flooding虛擬機時，每一臺攻擊虛擬機與被攻擊的目標虛擬機同駐的概率。該方案的總體思路為先大量投放虛擬機，再對所投放的虛擬機進行同駐檢測，將確定為同駐的虛擬機歸類，最后對所投放的虛擬機進行約減。具體步驟如下。

在實驗結果上有

記

顯然式(4)為凸函數，在式(6)中引入拉格朗日乘子，代入式(4)得

當式(7)取得最大值時，自變量偏導數為0，即

將式(4)、式(6)代入式(8)，有

由式(2)、式(9)可得

上述概率可以告知攻擊者如何進行下一步的攻擊實驗，并給予攻擊者理論上的指導。例如，優先從同駐發生率較高的物理主機開始進行同駐檢測，從而加快發現與目標同駐的速度。

4.2 基于合謀的同駐虛擬機遠程定位

當洪泛虛擬機數量達到一定程度時，可實現云平臺可用區物理主機的全部覆蓋。盡管如此，攻擊虛擬機如何定位目標虛擬機依舊困難。

文獻[4]提出，在云計算環境下，攻擊虛擬機可借助前面所述的內存總線沖突來實現云環境的拒絕服務（DoS, denial of service）攻擊，具體操作方式為不斷觸發內存總線沖突，正如構建隱蔽信道一般[30]，造成大量內存訪問時延，從而達到平臺上其他虛擬機無法正常使用內存的目的。除了該內存總線占用漏洞外，利用內存行錘擊漏洞也可造成虛擬化平臺的服務等級下降甚至停止。攻擊虛擬機可通過不斷錘擊具有關鍵數據的內存行（如Hypervisor所維護的EPT/NPT頁表），使整個虛擬化平臺暫停服務[2-3]。本文基于上述DDoS攻擊，結合合謀攻擊的思路，提出一種能夠快速定位目標虛擬機的方法。

5 同駐實驗與行業驗證

在對本文提出的同駐方案驗證之前，首先對所提的基于隱蔽信道的同駐檢測方案進行了實驗驗證，以確保該同駐檢測（判定）方案在之后的方案驗證中得到最大程度的效用。

5.1 虛擬機同駐判定

5.1.1 同駐閾值計算

為了確定傳輸正確率與虛擬機是否同駐之間的關系，選取分布在兩臺物理主機上的共10臺虛擬機之間進行隱蔽信道通信實驗。以基于內存總線的隱蔽信道為例，其傳輸正確率與同駐狀態如圖4所示。

圖4 傳輸正確率的多次采樣

其中，實際同駐的虛擬機共20對，非同駐的虛擬機共25對。實驗中，同駐虛擬機傳輸正確率最小值為90.7%，非同駐虛擬機傳輸正確率最大值為57.9%。兩類樣本間有明顯間隔，因此，可以通過設定傳輸準確率閾值判定虛擬機是否同駐。

實際上，當隱蔽信道的參數一定時，同駐虛擬機傳輸正確率與非同駐虛擬機傳輸正確率均為客觀上的定值。由于實驗數據的局限性和某些可能出現的噪聲的影響，傳輸正確率符合正態分布。為了確定虛擬機是否同駐的判定閾值，需要先由樣本估計出正態分布的參數，然后經過計算得到最優的判定閾值。

不同駐時傳輸正確率分布函數為

最優判定閾值應滿足

5.1.2 檢測效果評估

通過上述計算得到判定閾值后，重新對3臺同樣的物理主機上的共15臺確定編號的虛擬機進行隱蔽信道通信實驗。為了盡可能地模擬實際云平臺環境，所有虛擬機每15 min進行一次隨機遷移(目標主機不確定)。

以基于內存總線的隱蔽信道實現為測試工具，同樣每15 min對105對虛擬機進行同駐檢測，每次檢測持續8 s，持續測量1 h，實驗結果如表1所示。

表1 同駐檢測效果評估

通過表1可以看出，本文提出的同駐檢測方法具有極低的誤檢率和漏檢率。這一方面是由于對兩種隱蔽信道的實現做出了改進，且充分考慮到云環境中的噪聲和其他不良影響，對信道的通信進行了針對性的優化；另一方面是由于所設的判定閾值具有較好的置信度。隨后，本文提出的同駐檢測方法在實驗室環境中檢測成功的前提下，將此方法應用于商用云平臺的同駐檢測中，通過虛擬機洪泛碰撞的方式使兩臺云實例同駐。

5.2 同駐方案行業應用驗證

現階段，國內公有云服務競爭激烈。其中，某云平臺（下文中簡稱α云）作為行業標桿，其他公有云服務平臺架構與其極為類似。因此，為了使實驗結果具有標準性和普適性，本文選取α云作為目標，對其商業策略和服務等級協議進行研究，并在α云上有針對性地利用前面提出的VM flooding攻擊方案進行了一系列實驗。

目前，在物理基礎設施方面，α云提供了5個配置自由度，分別是：①地域；②可用區，可用區是指在同一地域內，電力和網絡互相獨立的物理區域，通常為一個機房；③~⑤實例系列，實例系列代表著不同的硬件系列，分別為系列Ⅰ、系列Ⅱ、系列Ⅲ。其中，不同系列采用不同的CPU類型，且其內存也不盡相同。在上述5個自由度中，前兩個（地域和可用區）屬于對地理位置的配置，而后3個屬于對實例類型的配置。本文選擇華南1-可用區A進行投放實驗，后續如無特殊說明，虛擬機實例都在該可用區創建。

5.2.1 自動化同駐檢測

為了能夠對每個虛擬機實例進行同駐檢測，每個虛擬機實例上都必須安裝隱蔽信道通信程序。因此，首先創建了一個含有隱蔽信道發送和接收程序的鏡像Image-covert-channel，其用戶操作系統為64 bit Ubuntu14.04。后續的虛擬機實例均以此鏡像為模板創建。

為了更進一步實現同駐檢測的自動化，本文基于Ansible開發了配置管理與自動化運行工具，通過SSH（secure shell）連接服務器并運行配置任務。它非常適合將bash腳本轉換成Ansible任務，并且由于其基于SSH，因此更易于檢查運行結果。Ansible同樣支持在α云或其他大型商用云（如Amazon EC2）中采用組（group）的形式管理虛擬機并遍歷組內的所有主機。由此，使用add_host模塊動態創建一個由這些新實例組成的group，便于在后續任務中立即在主機上執行所需操作。

圖5 ACD工作流程

5.2.2 同駐實驗案例研究

由于考慮到CPU核數和內存大的虛擬機可能被分配到更具特殊性的物理機中，首先用賬號甲同時創建了n1.small和n1.medium虛擬機實例各50臺，基于第3節提出的同駐檢測方法，對其進行兩兩檢測。檢測結果顯示，任意兩臺虛擬機都不同駐。再考慮到獨享型的虛擬機可能被分配到更具特殊性的物理機。繼續用賬號甲同時創建了n2.small和n2.medium虛擬機實例各50臺，對其進行兩兩檢測。檢測結果顯示，任意兩臺虛擬機都不同駐。結果如表2所示。

表2 單一賬號同時創建多臺虛擬機

基于上述推測可知，單一賬號的同駐情況并不理想。于是，本文調整最初的洪泛策略，使用多個賬號進行實驗。

首先，改用兩個賬號分別同時創建了5臺sn1.medium虛擬機實例，對其進行同駐檢測，檢測到一對虛擬機同駐，其實例ID分別為i-wz91n5w6 koukiloem6lj和i-wz952qiz9n49r2vj5yyg。

以i-wz91n5w6koukiloem6lj作為發送方，i-wz952qiz9n49r2vj5yyg作為接收方，采用經過調試的最優參數：=6 700、=300、=7，測量隱蔽信道傳輸正確率高達95.3%，其傳輸效果如圖6所示。其中，發送信息被封裝到一個frame中，“+”“?”分別代表所發送的“1”和“0”。后續如無特殊說明，所有同駐實驗均采用上述參數作為輸入。

(a) 發送方

(b) 接收方

圖6 隱蔽信道在α云上的檢測效果

之后，用甲、乙、丙這3個賬號分別同時各創建了5臺sn1.medium型實例，共15臺實例。為了進一步具體測量同駐產生率，本文分別使用兩個賬號同時創建5臺sn1.medium虛擬機及3個賬號同時創建5臺sn1.medium虛擬機，并進行50次重復實驗。其中，當兩個不同賬號同時創建medium型實例各5臺時，有48%的概率實現一對虛擬機同駐；當3個不同賬號同時創建實例各5臺時，有90%的概率出現至少一對虛擬機同駐，有82%的概率出現至少兩對虛擬機同駐，有52%的概率出現3對虛擬機同駐。另外，觀察到同駐的這兩臺虛擬機分別處于兩個不同的內網網段，因此判斷α云有極大可能使用了類似VPE[13]或VxLan的網絡隔離措施來構建安全組或私有云的網絡邊界。

采用更多的賬號進行了相同的實驗。當使用4個賬號甲、乙、丙、丁同時創建sn1.medium虛擬機實例時，共出現了35對同駐。其中，有兩臺物理機上同駐了4臺虛擬機，3臺物理機上同駐了3臺虛擬機，14臺物理機上同駐了兩臺虛擬機，另外，75臺物理機上只分配到一臺虛擬機，總計120臺虛擬機被部署到了94臺物理機上。同時，5個賬號與6個賬號同時創建共120臺虛擬機的同駐結果如表3所示。由表3可知，當賬號越多時，同駐情況越好，實證了5.2.1節所提出的假設。

接著，為了探究虛擬機同駐概率與實例類型之間的關系，本文對n1.tiny、sn1.medium、sn2.medium這3種類型的實例進行了實驗。此次實驗使用了12個賬號同時各創建一臺虛擬機，重復實驗50次，同駐結果如表4所示。可以看出，sn1.medium型實例的平均同駐對數略高于其他兩種類型。

表3 多賬號同時創建多臺虛擬機

表4 多賬號同時創建不同類型實例

由上述分析可知：當賬號越多時，同駐比例越大；當實例類型為sn1.medium時，同駐比例最大。因此，為了進一步對本文所提的洪泛策略進行改進與實驗驗證，在36 d時間內α云使用高峰時間段（晚8時—晚9時），使用12個賬號同時開啟共360臺、480臺和600臺sn1.medium型實例各10次。具體情況如圖7所示。

圖7 大規模虛擬機實例洪泛

由圖7(c)可知，110臺物理主機中，載有5個和6個同駐虛擬機的數量最多，分別有32臺和31臺。所有的物理主機均有3個及以上同駐虛擬機，單臺物理主機上最大的同駐虛擬機數為9。由第4節結論可知：在同一時間再開啟10~15個虛擬機，有約15%~21%的概率使攻擊虛擬機與這9個目標虛擬機同駐。另外，在所有的12個賬號中，每50個實例均被投放到了40~43臺物理主機上，其中，載有兩個虛擬機的物理主機均不少于6臺。

圖8顯示了采用上述基于后驗概率洪泛策略進行有針對性的虛擬機投放時，僅使用2、5、10個賬號迭代開啟虛擬機時同駐的覆蓋率。從圖8可以看到，當投放數量超過100時，同駐覆蓋率有大幅提升；當使用5個不同賬號投放72次（360臺虛擬機實例）時，同駐覆蓋率就已經接近90%；當使用10個不同賬號投放25次時，覆蓋率超過95%；當投放實例數超過500時，無論使用多少數量的賬號，都可基本實現全部覆蓋。

圖8 同駐覆蓋比

5.2.3 實驗結果分析

通過歷時多個月的同駐實驗，可以發現與驗證如下規律。

1) 現階段α云對于同駐威脅做出了基本的防護，采取了一些簡單的應對措施。首先，ICMP分組被禁止使用于網絡探測，不同用戶的虛擬機之間的網絡與其所處的物理主機無關。其次，同一賬號的虛擬機在正常情況下無法被分配到同一物理機。

2) 不同賬號同時創建相同可用區、相同實例類型的虛擬機時，產生同駐的可能性極大，且采用的賬號越多，攻擊成功率越高。實例類型對于同駐率的影響不大。

3) 當啟動大量的虛擬機來進行VM flooding實驗時，由于物理主機的數量遠小于開啟的實例數，同一賬號的虛擬機無法被分配到同一物理機的規律被打破。在同一時間大量虛擬機被分布在百余臺物理主機上，基本覆蓋了該可用區子網的物理主機，充分說明了該洪泛策略的可行性。

6 結束語

本文對適用于商用云平臺的虛擬機同駐方案進行了研究。以“先假設，后驗證”的方式來完成攻擊虛擬機與目標虛擬機的同駐，且在強安全條件下依舊有效。該方案能夠使攻擊者快速實現惡意虛擬機與目標虛擬機的同駐，盡可能地減少不必要的開銷。

[1] DESNOS A, FILIOL E, LEFOU I, et al. Detecting (and creating!) a HVM rootkit (aka BluePill-like)[J]. Journal in Computer Virology, 2011, 7(1): 23-49.

[2] RAZAVI K, GRAS B, BOSMAN E, et al. Flip feng shui: hammering a needle in the software stack[C]//Usenix Security Symposium. 2016: 1-18.

[3] XIAO Y, ZHANG X, ZHANG Y, et al. One bit flips, one cloud flops: cross-VM row hammer attacks and privilege escalation[C]//Usenix Security Symposium. 2016: 19-35.

[4] ZHANG T, ZHANG Y, LEE R. DoS attacks on your memory in the cloud[C]//ACM Symposium on Information, Computer and Communications Security. 2017: 253-265.

[5] IRAZOQUI G, INCI M S, EISENBARTH T, et al. Fine grain cross-VM attacks on Xen and VMware[C]//ACM Conference on Cloud Computing. 2014: 737-744.

[6] IRAZOQUI G, INCI M S, EISENBARTH T, et al. Wait a minute! a fast, cross-VM attack on AES[C]//International Symposium on Recent Advances in Intrusion Detection. 2014: 299-319.

[7] LIU F, YAROM Y, GE Q, et al. Last-level cache side-channel attacks are practical[C]//IEEE Symposium on Security and Privacy. 2015: 605-622.

[8] IRAZOQUI G, EISENBARTH T, SUNAR B, et al. Cross processor cache attacks[C]//ACM Conference on Computer and Communications Security. 2016: 353-364.

[9] YAROM Y, GENKIN D, HENINGER N, et al. CacheBleed: a timing attack on OpenSSL constant time RSA[C]//International Workshop on Cryptographic Hardware and Embedded Systems. 2016: 346-367.

[10] RISTENPART T, TROMER E, SHACHAM H, et al. Hey, you, get off of my cloud: exploring information leakage in third-party compute clouds[C]//ACM Conference on Computer and Communications Security. 2009: 199-212.

[11] BATES A, MOOD B, PLETCHER J, et al. Detecting co-residency with active traffic analysis techniques[C]//ACM Conference on Cloud Computing. 2012: 1-12.

[12] XU Z, WANG H, WU Z, et al. A measurement study on co-residence threat inside the cloud[C]//Usenix Security Symposium. 2015: 929-944.

[13] 王麗娜, 張浩, 余榮威, 等. 基于VPE的可信虛擬域構建機制[J]. 通信學報, 2013, 34(12): 167-177.

WANG L N, ZHANG H, YU R W, et al. Building mechanism of trusted virtual domain via the VPE[J]. Journal on Communications, 2013, 34(12): 167-177.

[14] ZHANG Y, JUELS A, OPREA A, et al. HomeAlone: co-residency detection in the cloud via side-channel analysis[C]//IEEE Symposium on Security and Privacy. 2011: 313-328.

[15] 余思, 桂小林, 張學軍, 等. 云環境中基于cache共享的虛擬機同駐檢測方法[J]. 計算機研究與發展, 2013, 50(12): 2651-2660.

YU S, GUI X L, ZHANG X J, et al. Co-residency detection scheme based on shared cache in the cloud[J]. Journal of Computer Research and Development, 2013, 50(12): 2651-2660.

[16] LIU F, GE Q, YAROM Y, et al. CATalyst: defeating last-level cache side channel attacks in cloud computing[C]//IEEE International Symposium on High Performance Computer Architecture. 2016: 406-418.

[17] 梁鑫, 桂小林, 戴慧珺, 等. 云環境中跨虛擬機的cache側信道攻擊技術研究[J]. 計算機學報, 2017, 40(2): 317-336.

LIANG X, GUI X L, DAI H J, et al. Cross-VM cache side channel attacks in cloud: a survey[J]. Chinese Journal of Computers, 2017, 40(2): 317-336.

[18] 王國峰, 劉川意, 潘鶴中, 等. 云計算模式內部威脅綜述[J]. 計算機學報, 2017, 40(2): 296–316.

WANG G F, LIU C Y, PAN H Z, et al. Survey on insider threats to cloud computing[J]. Chinese Journal of Computers, 2017, 40(2): 296-316.

[19] WANG L, LIU W, KUMAR N, et al. A novel covert channel detection method in cloud based on XSRM and improved event association algorithm[J]. Security and Communication Networks, 2016, 9(16): 3543-3557.

[20] IRAZOQUI G, EISENBARTH T, SUNAR B, et al. S$A: a shared cache attack that works across cores and defies VM sandboxing-and its application to AES[C]//IEEE Symposium on Security and Privacy. 2015: 591-604.

[21] 沈晴霓, 李卿. 云計算環境中的虛擬機同駐安全問題綜述[J]. 集成技術, 2015, 4(5): 5-17.

SHEN Q N, LI Q. Review on co-residency security issues of virtual machines in cloud computing[J]. Journal of Integration Technology, 2015, 4(5): 5-17.

[22] OSVIK D A, SHAMIR A, TROMER E. Cache attacks and countermeasures: the case of AES[C]//Cryptographers’ Track at the RSA Conference. 2006: 1-20.

[23] YAROM Y, FALKNER K. FLUSH+RELOAD: a high resolution, low noise, L3 cache side-channel attack[C]//Usenix Security Symposium. 2014: 719-732.

[24] MAURICE C, SCOUARNEC N L, NEUMANN C, et al. Reverse engineering intel last-level cache complex addressing using performance counters[C]//International Symposium on Recent Advances in Intrusion Detection. 2015: 48-65.

[25] IRAZOQUI G, EISENBARTH T, SUNAR B, et al. Systematic reverse engineering of cache slice selection in intel processors[C]//Euromicro Conference on Digital Systems Design. 2015: 629-636.

[26] WU Z, XU Z, WANG H, et al. Whispers in the hyper-space: high-bandwidth and reliable covert channel attacks inside the cloud[J]. IEEE/ACM Transactions on Networking, 2015, 23(2): 603-615.

[27] PAAR C, PELZL J. Understanding cryptography: a textbook for students and practitioners[M]. Springer Science & Business Media, 2009.

[28] LI P, GAO D, REITER M K, et al. Replica placement for availability in the worst case[C]//International Conference on Distributed Computing Systems. 2015: 599-608.

[29] MOON S, SEKAR V, REITER M K, et al. Nomad: mitigating arbitrary cloud side channels via provider-assisted migration[C]//ACM Conference on Computer and Communications Security. 2015: 1595-1606.

[30] LIU W, GAO D, REITER M K. On-demand time blurring to support side-channel defense[C]//European Symposium on Research in Computer Security. 2017:210-228.

[31] NEEDLEMAN S B, WUNSCH C D. A general method applicable to the search for similarities in the amino acid sequence of two proteins[J]. Journal of Molecular Biology, 1970, 48(3): 443-453.

[32] VARADARAJAN V, ZHANG Y, RISTENPART T, et al. A placement vulnerability study in multi-tenant public clouds[C]//Usenix Security Symposium. 2015:913-928.

Virtual machine co-residency method on cloud computing platform

LIU Weijie1,2, WANG Li’na1,2, WANG Danlei1,2, YIN Zhengguang3, FU Nan1,2

1. Key Laboratory of Aerospace Information Security and Trusted Computing, Ministry of Education, Wuhan 430079, China 2. School of Cyber Science and Engineering, Wuhan University, Wuhan 430079, China 3. Alibaba Cloud Computing Co., Ltd., Hangzhou 311121, China

If the attacker wants to compromise a target virtual machine on a cloud platform, the malicious virtual machine must be co-resident with the target. Based on this, a virtual machine co-residency method was proposed. The method combined a co-residency detection scheme based on covert channel construction and an automatic virtual machine flooding strategy, and was evaluated on a well-known domestic cloud platform. Experiment shows that the adaptive covert channel can achieve accuracies of 95%, the proposed detection scheme has strong robustness whose false positive rate is less than 5 ‰, the proposed method is versatile and keeps the virtualization isolation barrier intact, which has great potential threat and should be paid great attention and precaution.

cloud computing platform, virtual machine co-residency, covert channel, virtual machine flooding

TP309

A

10.11959/j.issn.1000?436x.2018241

劉維杰（1991–），男，湖北武漢人，武漢大學博士生，主要研究方向為虛擬化安全、圖像處理等。

王麗娜（1964–），女，遼寧營口人，博士，武漢大學教授、博士生導師，主要研究方向為多媒體安全、云計算安全、可信計算等。

王丹磊（1992–），男，湖北武漢人，武漢大學碩士生，主要研究方向為機器學習、信息內容安全等。

尹正光（1989–），男，江西吉安人，碩士，阿里云計算有限公司高級開發工程師，主要研究方向為cloud native和IaaS架構等。

付楠（1993–），女，江西九江人，武漢大學碩士生，主要研究方向為網絡安全、云計算安全等。

2018?04?03；

2018?06?29

王麗娜，lnwang@whu.edu.cn

國家自然科學基金資助項目（No.U1536204）；中央高校基本科研業務費專項基金資助項目（No.2042018kf1028）

The National Natural Science Foundation of China (No.U1536204), The Central University Basic Business Expenses Special Funding for Scientific Research Project (No.2042018kf1028)