9月23日，XEN官方來了個帽子戲法，一口氣爆出3個漏洞。隨后，就有關于亞馬遜AWS大規(guī)模重啟服務器的消息爆出。這次重啟事件不論是影響到的產品、還是持續(xù)的時間都是史無前例的，整個修復周期持續(xù)5天，從9月25日下午7點到9月30日下午5點，影響的產品包括EC2、RDS、ElastiCache、RedShift，其中EC2最為嚴重，大約占到AWS EC2總量的10%.由于是發(fā)生在美國，所以國內這塊的報道較少，很多同學可能還不知道是什么漏洞，讓亞馬遜做如此大范圍的重啟操作。下面我們一塊看看這三兄弟到底是啥來頭。

這次的三個漏洞，危害有哪些？

1、CVE-2014-7154這個可以說是三兄弟中的老大，為何？因為它在關鍵位置有人，因為它老爹是dom0.dom0在XEN架構中的地位非常重要，它包含控制硬件的驅動和控制虛擬機的工具集。所以它會影響到整個物理機上面所有的虛擬機，這樣的漏洞是最恐怖的，波及范圍廣，修補起來又需要重啟，那就得業(yè)務中斷啊，還有，如果重啟起不來咋辦？？ 

2、CVE-2014-7155這個可以排行老二，客戶機可以利用該漏洞加載自己的IDT或GDT，可能導致虛擬機的宕機，還可以獲取root權限。看到這里我們也不要太慌張，因為這里不是虛擬機逃逸，而是獲取虛擬機的root權限。危害也不小，“黑闊”又多了一個提權利器。

3、CVE-2014-7156與上述那倆老大哥比起來，就個漏洞危害就要差一些了。利用該漏洞，可能導致虛擬機的宕機，但宕機也不是小事，不容小覷，只是生不逢時。

神馬是XEN？

在進行技術分析之前，我們先了解一下關于XEN的背景知識。

VMware大家都很熟悉了，無論是WorkStation還是企業(yè)級的ESX，XEN就是類似于ESX的一個軟件，不過是開源的（類似的還有KVM)。現在KVM已經是Linux官方加入到內核中的虛擬化技術。

XEN最早由劍橋大學開發(fā)，現在被Citrix收購，亞馬遜的AWS就是基于XEN技術的。

通過下圖我們來了解下XEN技術架構：

從上面可以看出，XEN hypervisor直接運行在硬件之上，負責處理CPU、內存、中斷等。它是運行完bootloader之后第一個運行的程序。在hypervisor之上允許虛擬機，在XEN里面，一個虛擬機實例被稱為domain或者guest.其中，domain0是一個特殊的domain，它包含所有控制硬件的驅動，同時包含控制管理虛擬機的工具集。

除了domain0之外，其它的虛擬機就是我們熟悉的guest，大致分為兩種類型：Paravirtualization（PV）半虛擬化 和 Full Virtualization（HVM）全虛擬化。

PV是由XEN引入的，后來被其它虛擬化平臺采用。半虛擬化是一種高效、輕量的虛擬化技術，它不需要物理機CPU含有虛擬化擴展，但卻需要一個Xen-PV-enabled內核和PV驅動，說白了就是需要修改虛機系統(tǒng)的內核，好在Linux、BSD、OpenSolaris等提供了該內核，但是Windows就不行了，因為只有微軟可以修改它的內核。

HVM使用了物理機CPU的虛擬化擴展來虛擬出虛擬機。該技術需要Intel VT或者AMD-V硬件擴展。Xen使用Qemu來仿真PC硬件，包括BIOS、IDE硬盤控制器、VGA、USB控制器、網卡等等。由于使用虛擬機硬件擴展來提高仿真性能，所以HVM不需要修改內核，因此其上可以運行Windows系統(tǒng)。

技術揭秘

現在我們大致了解了這三漏洞有啥危害了，下面我們跟著官方的漏洞通告和補丁文件，來具體分析下這些漏洞。

1、CVE-2014-7154

CVE-2014-7154說的是在HVMOP_track_dirty_vram里面存在竟態(tài)條件，HVMOP_track_dirty_vram是一個用來控制臟顯存跟蹤設置的函數。下面是官方給出的補丁：

p2m_type_t t；- struct sh_dirty_vram *dirty_vram = d->arch.hvm_domain.dirty_vram；+ struct sh_dirty_vram *dirty_vram；struct p2m_domain *p2m = p2m_get_hostp2m（d）；

if （ end_pfn < begin_pfn || end_pfn > p2m->max_mapped_pfn + 1 ）

@@ -3495，6 +3495，8 @@ int shadow_track_dirty_vram（struct domai p2m_lock（p2m_get_hostp2m（d））；paging_lock（d）；

+ dirty_vram = d->arch.hvm_domain.dirty_vram；+ if （ dirty_vram && （！nr ||

從補丁中可以看出，在沒有打補丁的代碼里，系統(tǒng)在獲取paging_lock之前，已經獲取到了dirty_vram的值。這里有一個潛在的問題，兩個并發(fā)的hypercall會嘗試同時釋放dirty_vram，那么兩者中，第二個嘗試進行釋放的是一個野指針。另外，兩個并發(fā)的hypercall也可能會嘗試同時創(chuàng)建一個新的dirty_vram結構體，那么最先創(chuàng)建的那塊內存會泄漏，因為第二個dirty_vram創(chuàng)建之后，兩個指針都指向新的dirty_vram結構體。

所以修補起來也很簡單，就是將獲取d->arch.hvm_domain.dirty_vram的值放到獲取了paging_lock之后。

2、CVE-2014-7155 CVE-2014-7155講的是在x86的HLT、LGDT、LIDT、LMSW指令模擬時沒有做特權檢查，這些指令都是用來加載全局描述附表、中斷描述符表或者局部描述符表等。惡意的客戶機程序可以安裝自己的IDT（中斷描述符表），這些惡意行為會導致客戶機宕機，或者進行提權。

case 0xf4： /* hlt */ + generate_exception_if（！mode_ring0（）， EXC_GP， 0）；ctxt->retire.flags.hlt = 1；break；

@@ -3710，6 +3711，7 @@ x86_emulate（break；case 2： /* lgdt */ case 3： /* lidt */ + generate_exception_if（！mode_ring0（）， EXC_GP， 0）；generate_exception_if（ea.type ！= OP_MEM， EXC_UD， -1）；fail_if（ops->write_segment == NULL）；memset（&reg， 0， sizeof（reg））；@@ -3738，6 +3740，7 @@ x86_emulate（case 6： /* lmsw */ fail_if（ops->read_cr == NULL）；fail_if（ops->write_cr == NULL）；+ generate_exception_if（！mode_ring0（）， EXC_GP， 0）；if （ （rc = ops->read_cr（0， &cr0， ctxt）） ）

goto done；

從補丁中可以看出，系統(tǒng)通過在模擬htl、lgdt、lidt、lmsw的時候，增加了generate_exception_if（）宏來解決該問題。該宏對運行在非ring0模式下的htl等指令，會產生EXC_GP異常。下面是generate_exception_if的宏定義：

#define generate_exception_if（p， e， ec） \（{ if （ （p） ） { \ fail_if（ops->inject_hw_exception == NULL）； \ rc = ops->inject_hw_exception（e， ec， ctxt） ？ ： X86EMUL_EXCEPTION； \ goto done； \ } \ }）

從generate_exception_if（！mode_ring0（）， EXC_GP， 0）

可以看出，對運行在ring0模式的指令不做任何操作，對運行在非ring0模式的指令，執(zhí)行了檢查。首先看是否定義了inject_hw_exception函數，如果沒有定義，則ops->injdect_hw_exception == NULL的結果為真，根據fail_if的宏定義可以發(fā)現直接產生X86EMUL_UNHANDLEABLE：

#define fail_if（p） \ do { \ rc = （p） ？ X86EMUL_UNHANDLEABLE ： X86EMUL_OKAY； \ if （ rc ） goto done； \ } while （0）

如果在ops中定義了inject_hw_excption，則調用hvmemul_inject_hw_exceptio（）函數來設置該異常的相關信息：

static int hvmemul_inject_hw_exception（uint8_t vector，int32_t error_code，struct x86_emulate_ctxt *ctxt）

{ struct hvm_emulate_ctxt *hvmemul_ctxt = container_of（ctxt， struct hvm_emulate_ctxt， ctxt）；

hvmemul_ctxt->exn_pending = 1；hvmemul_ctxt->exn_vector = vector；hvmemul_ctxt->exn_error_code = error_code；hvmemul_ctxt->exn_insn_len = 0；

return X86EMUL_OKAY；}

通過查看宏定義，發(fā)現X86EMUL_OKAY的值為0：

/* Completed successfully. State modified appropriately. */ #define X86EMUL_OKAY 0 /* Unhandleable access or emulation. No state modified. */ #define X86EMUL_UNHANDLEABLE 1 /* Exception raised and requires delivery. */ #define X86EMUL_EXCEPTION 2

所以當inject_hw_exception不為NULL的時候，generate_exception_if在調用hvmemul_inject_hw_exception設置完相應的異常信息之后，產生X86EMUL_EXCEPTION異常。從上面的宏定義可以看出，不論是X86EMUL_UNHANDLEABLE異常還是X86EMUL_EXCEPTION異常，都會導致指令不執(zhí)行。

3、CVE-2014-7156 CVE-2014-7156講的是在x86中模擬軟中斷的時候，沒有做特權檢查，惡意的HVM客戶機上面的代碼能夠使客戶機宕機。

補丁說明只允許在實模式中進行軟中斷模擬，所以補丁也很簡單，檢測到在非實模式下模擬軟中斷的時候就退出：

case 0xcd： /* int imm8 */ src.val = insn_fetch_type（uint8_t）；swint：+ fail_if（！in_realmode（ctxt， ops））； /* XSA-106 */ fail_if（ops->inject_sw_interrupt == NULL）

總結

其實我們看看3個補丁，發(fā)現貌似沒做啥啊，只是換了換代碼的位置，或加了一個函數或者宏。這說明XEN其實已經有解決問題的方案，只不過在某些指令的處理上，沒有考慮到所有的使用場景，因此漏掉了相應的檢查。那是不是其它指令在某些場景下還會有類似的問題呢？嘿嘿，我只能說漏洞時時有，這陣子特別多，所以我們多關注關注XEN的官方漏洞通告頁面就知道了。

再看看IaaS云老大亞馬遜AWS，不得不說他們的響應速度很快，對安全也重視，沒有僥幸心理，該補的補，該重啟的重啟，重視安全的態(tài)度由此可見。但話說回來，出發(fā)點雖好，但是有沒有更好的處理方式呢，既可以修補漏洞又可以不重啟服務器的？

必須有！UCloud的內核團隊這方面有很深入的研究：內核熱補丁。通過該技術可以給運行中的Linux服務器打上內核補丁，既可以解決存在的問題，最重要的是不需要重啟服務器。這項技術在UCloud已經廣泛使用，已經免重啟修復過十幾個內核BUG.