9月23日，XEN官方來了個(gè)帽子戲法，一口氣爆出3個(gè)漏洞。隨后，就有關(guān)于亞馬遜AWS大規(guī)模重啟服務(wù)器的消息爆出。這次重啟事件不論是影響到的產(chǎn)品、還是持續(xù)的時(shí)間都是史無前例的，整個(gè)修復(fù)周期持續(xù)5天，從9月25日下午7點(diǎn)到9月30日下午5點(diǎn)，影響的產(chǎn)品包括EC2、RDS、ElastiCache、RedShift，其中EC2最為嚴(yán)重，大約占到AWS EC2總量的10%.由于是發(fā)生在美國(guó)，所以國(guó)內(nèi)這塊的報(bào)道較少，很多同學(xué)可能還不知道是什么漏洞，讓亞馬遜做如此大范圍的重啟操作。下面我們一塊看看這三兄弟到底是啥來頭。
這次的三個(gè)漏洞，危害有哪些？
1、CVE-2014-7154這個(gè)可以說是三兄弟中的老大，為何？因?yàn)樗陉P(guān)鍵位置有人，因?yàn)樗系莇om0.dom0在XEN架構(gòu)中的地位非常重要，它包含控制硬件的驅(qū)動(dòng)和控制虛擬機(jī)的工具集。所以它會(huì)影響到整個(gè)物理機(jī)上面所有的虛擬機(jī)，這樣的漏洞是最恐怖的，波及范圍廣，修補(bǔ)起來又需要重啟，那就得業(yè)務(wù)中斷啊，還有，如果重啟起不來咋辦？？
2、CVE-2014-7155這個(gè)可以排行老二，客戶機(jī)可以利用該漏洞加載自己的IDT或GDT，可能導(dǎo)致虛擬機(jī)的宕機(jī)，還可以獲取root權(quán)限。看到這里我們也不要太慌張，因?yàn)檫@里不是虛擬機(jī)逃逸，而是獲取虛擬機(jī)的root權(quán)限。危害也不小，“黑闊”又多了一個(gè)提權(quán)利器。
3、CVE-2014-7156與上述那倆老大哥比起來，就個(gè)漏洞危害就要差一些了。利用該漏洞，可能導(dǎo)致虛擬機(jī)的宕機(jī)，但宕機(jī)也不是小事，不容小覷，只是生不逢時(shí)。
神馬是XEN？
在進(jìn)行技術(shù)分析之前，我們先了解一下關(guān)于XEN的背景知識(shí)。
VMware大家都很熟悉了，無論是WorkStation還是企業(yè)級(jí)的ESX，XEN就是類似于ESX的一個(gè)軟件，不過是開源的（類似的還有KVM)?，F(xiàn)在KVM已經(jīng)是Linux官方加入到內(nèi)核中的虛擬化技術(shù)。
XEN最早由劍橋大學(xué)開發(fā)，現(xiàn)在被Citrix收購(gòu)，亞馬遜的AWS就是基于XEN技術(shù)的。
通過下圖我們來了解下XEN技術(shù)架構(gòu)：
從上面可以看出，XEN hypervisor直接運(yùn)行在硬件之上，負(fù)責(zé)處理CPU、內(nèi)存、中斷等。它是運(yùn)行完bootloader之后第一個(gè)運(yùn)行的程序。在hypervisor之上允許虛擬機(jī)，在XEN里面，一個(gè)虛擬機(jī)實(shí)例被稱為domain或者guest.其中，domain0是一個(gè)特殊的domain，它包含所有控制硬件的驅(qū)動(dòng)，同時(shí)包含控制管理虛擬機(jī)的工具集。
除了domain0之外，其它的虛擬機(jī)就是我們熟悉的guest，大致分為兩種類型：Paravirtualization（PV）半虛擬化 和 Full Virtualization（HVM）全虛擬化。
PV是由XEN引入的，后來被其它虛擬化平臺(tái)采用。半虛擬化是一種高效、輕量的虛擬化技術(shù)，它不需要物理機(jī)CPU含有虛擬化擴(kuò)展，但卻需要一個(gè)Xen-PV-enabled內(nèi)核和PV驅(qū)動(dòng)，說白了就是需要修改虛機(jī)系統(tǒng)的內(nèi)核，好在Linux、BSD、OpenSolaris等提供了該內(nèi)核，但是Windows就不行了，因?yàn)橹挥形④浛梢孕薷乃膬?nèi)核。
HVM使用了物理機(jī)CPU的虛擬化擴(kuò)展來虛擬出虛擬機(jī)。該技術(shù)需要Intel VT或者AMD-V硬件擴(kuò)展。Xen使用Qemu來仿真PC硬件，包括BIOS、IDE硬盤控制器、VGA、USB控制器、網(wǎng)卡等等。由于使用虛擬機(jī)硬件擴(kuò)展來提高仿真性能，所以HVM不需要修改內(nèi)核，因此其上可以運(yùn)行Windows系統(tǒng)。
技術(shù)揭秘
現(xiàn)在我們大致了解了這三漏洞有啥危害了，下面我們跟著官方的漏洞通告和補(bǔ)丁文件，來具體分析下這些漏洞。
1、CVE-2014-7154
CVE-2014-7154說的是在HVMOP_track_dirty_vram里面存在竟態(tài)條件，HVMOP_track_dirty_vram是一個(gè)用來控制臟顯存跟蹤設(shè)置的函數(shù)。下面是官方給出的補(bǔ)?。?/p>
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 ||
從補(bǔ)丁中可以看出，在沒有打補(bǔ)丁的代碼里，系統(tǒng)在獲取paging_lock之前，已經(jīng)獲取到了dirty_vram的值。這里有一個(gè)潛在的問題，兩個(gè)并發(fā)的hypercall會(huì)嘗試同時(shí)釋放dirty_vram，那么兩者中，第二個(gè)嘗試進(jìn)行釋放的是一個(gè)野指針。另外，兩個(gè)并發(fā)的hypercall也可能會(huì)嘗試同時(shí)創(chuàng)建一個(gè)新的dirty_vram結(jié)構(gòu)體，那么最先創(chuàng)建的那塊內(nèi)存會(huì)泄漏，因?yàn)榈诙€(gè)dirty_vram創(chuàng)建之后，兩個(gè)指針都指向新的dirty_vram結(jié)構(gòu)體。
所以修補(bǔ)起來也很簡(jiǎn)單，就是將獲取d->arch.hvm_domain.dirty_vram的值放到獲取了paging_lock之后。
2、CVE-2014-7155 CVE-2014-7155講的是在x86的HLT、LGDT、LIDT、LMSW指令模擬時(shí)沒有做特權(quán)檢查，這些指令都是用來加載全局描述附表、中斷描述符表或者局部描述符表等。惡意的客戶機(jī)程序可以安裝自己的IDT（中斷描述符表），這些惡意行為會(huì)導(dǎo)致客戶機(jī)宕機(jī)，或者進(jìn)行提權(quán)。
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（®， 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；
從補(bǔ)丁中可以看出，系統(tǒng)通過在模擬htl、lgdt、lidt、lmsw的時(shí)候，增加了generate_exception_if（）宏來解決該問題。該宏對(duì)運(yùn)行在非ring0模式下的htl等指令，會(huì)產(chǎn)生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）
可以看出，對(duì)運(yùn)行在ring0模式的指令不做任何操作，對(duì)運(yùn)行在非ring0模式的指令，執(zhí)行了檢查。首先看是否定義了inject_hw_exception函數(shù)，如果沒有定義，則ops->injdect_hw_exception == NULL的結(jié)果為真，根據(jù)fail_if的宏定義可以發(fā)現(xiàn)直接產(chǎn)生X86EMUL_UNHANDLEABLE：
#define fail_if（p） \ do { \ rc = （p） ？ X86EMUL_UNHANDLEABLE ： X86EMUL_OKAY； \ if （ rc ） goto done； \ } while （0）
如果在ops中定義了inject_hw_excption，則調(diào)用hvmemul_inject_hw_exceptio（）函數(shù)來設(shè)置該異常的相關(guān)信息：
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ā)現(xiàn)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
所以當(dāng)inject_hw_exception不為NULL的時(shí)候，generate_exception_if在調(diào)用hvmemul_inject_hw_exception設(shè)置完相應(yīng)的異常信息之后，產(chǎn)生X86EMUL_EXCEPTION異常。從上面的宏定義可以看出，不論是X86EMUL_UNHANDLEABLE異常還是X86EMUL_EXCEPTION異常，都會(huì)導(dǎo)致指令不執(zhí)行。
3、CVE-2014-7156 CVE-2014-7156講的是在x86中模擬軟中斷的時(shí)候，沒有做特權(quán)檢查，惡意的HVM客戶機(jī)上面的代碼能夠使客戶機(jī)宕機(jī)。
補(bǔ)丁說明只允許在實(shí)模式中進(jìn)行軟中斷模擬，所以補(bǔ)丁也很簡(jiǎn)單，檢測(cè)到在非實(shí)模式下模擬軟中斷的時(shí)候就退出：
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）
總結(jié)
其實(shí)我們看看3個(gè)補(bǔ)丁，發(fā)現(xiàn)貌似沒做啥啊，只是換了換代碼的位置，或加了一個(gè)函數(shù)或者宏。這說明XEN其實(shí)已經(jīng)有解決問題的方案，只不過在某些指令的處理上，沒有考慮到所有的使用場(chǎng)景，因此漏掉了相應(yīng)的檢查。那是不是其它指令在某些場(chǎng)景下還會(huì)有類似的問題呢？嘿嘿，我只能說漏洞時(shí)時(shí)有，這陣子特別多，所以我們多關(guān)注關(guān)注XEN的官方漏洞通告頁面就知道了。
再看看IaaS云老大亞馬遜AWS，不得不說他們的響應(yīng)速度很快，對(duì)安全也重視，沒有僥幸心理，該補(bǔ)的補(bǔ)，該重啟的重啟，重視安全的態(tài)度由此可見。但話說回來，出發(fā)點(diǎn)雖好，但是有沒有更好的處理方式呢，既可以修補(bǔ)漏洞又可以不重啟服務(wù)器的？
必須有！UCloud的內(nèi)核團(tuán)隊(duì)這方面有很深入的研究：內(nèi)核熱補(bǔ)丁。通過該技術(shù)可以給運(yùn)行中的Linux服務(wù)器打上內(nèi)核補(bǔ)丁，既可以解決存在的問題，最重要的是不需要重啟服務(wù)器。這項(xiàng)技術(shù)在UCloud已經(jīng)廣泛使用，已經(jīng)免重啟修復(fù)過十幾個(gè)內(nèi)核BUG.
