信息來源：FreeBuf   

近日，Nettitude安全人員在Avast Virtualization內(nèi)核模式驅動(aswSnx.sys)中發(fā)現(xiàn)一個安全漏洞，使用普通賬戶登錄的本地攻擊者可利用該漏洞提升權限，以系統(tǒng)權限執(zhí)行任意代碼，進而完全控制受影響主機。

AvastVirtualization(aswSnx.sys)驅動用于處理所有Avast Windows產(chǎn)品的“Sandbox”和“DeepScreen”功能。

受影響產(chǎn)品及版本

Avast InternetSecurity v11.1.2245

Avast ProAntivirus v11.1.2245

Avast Premierv11.1.2245

Avast FreeAntivirus v11.1.2245

上述產(chǎn)品中的早期版本也可能受到影響。

技術細節(jié)

AvastVirtualization內(nèi)核模式驅動(aswSnx.sys)沒有驗證用戶空間的IOCTL請求中的Unicode文件絕對路徑的長度，而該路徑長度會被復制到固定大小的分頁池內(nèi)存中，攻擊者可以借助特制的代碼導致內(nèi)核分頁池分配的數(shù)據(jù)塊溢出，并損壞其相鄰的攻擊者控制的內(nèi)核對象，如圖一。

圖一 攻擊者控制的內(nèi)核對象

圖二顯示了aswSnx.sys驅動對nt!memmove函數(shù)的調(diào)用，但是這一過程沒有驗證數(shù)據(jù)是否按可用大小被復制到分頁池的數(shù)據(jù)塊中。這些信息取自10.x版本，同樣適用于11.x版本。

圖二 漏洞原因

堆緩沖區(qū)溢出的利用

在處理基于緩沖區(qū)的動態(tài)內(nèi)存分配，也就是基于堆的緩沖區(qū)溢出時，首先需要預測緩沖區(qū)溢出發(fā)生的位置，以便于控制該漏洞的執(zhí)行。這在處理內(nèi)核地址空間的代碼運行時是十分重要的，因為如果利用失敗，系統(tǒng)可能會出現(xiàn)故障。損壞一個不可控制的隨機內(nèi)核對象實在不是一個明智的選擇。

為了達到這個目的，面臨的另一個挑戰(zhàn)就是，根據(jù)數(shù)據(jù)塊的大小創(chuàng)建一個合理的動態(tài)內(nèi)存分配布局，用于溢出的產(chǎn)生。如果已知數(shù)據(jù)塊的大小，那么我們就可以沒有更多限制的實現(xiàn)這個目的。然而，當我們處理固定掉的數(shù)據(jù)塊（在該實例中為0×418字節(jié)），很難找到一個合適大小的對象導致堆溢出。想要克服該問題的人可以參考此處。

溢出內(nèi)核分頁池

私有命名空間是創(chuàng)建可控大小的分頁池對象的有效方法。通過創(chuàng)建多個帶有邊界描述符名稱的、特制長度的私有命名空間，我們可以獲得以下內(nèi)存布局：

圖三 堆溢出#1

因此，在這種情況下，我們并不能控制分頁池數(shù)據(jù)塊的大小，但是，我們可以控制分頁池對象的大小，如圖三所示，指定一個內(nèi)存頁（4KB）來顯示分頁池的開始。

也就是說，我們可以創(chuàng)建一個控制內(nèi)存頁開始的對象，然后就可以擁有一個0x3b8字節(jié)大小的可用空間，和兩個一直到內(nèi)存頁結束都可以控制的相鄰對象。由于邊界描述符名稱的長度可變，甚至可以使用可控對象占據(jù)整個內(nèi)存頁。

圖四 堆溢出#2

但是，由于可溢出的緩沖區(qū)是固定大?。?×418字節(jié)）的，并且可以以內(nèi)存頁中最后分配的對象為目標，因此我們完全不用考慮page_allocation_base + 0×418中的空間內(nèi)容。也就是說，我們?nèi)匀豢梢栽试S內(nèi)核使用該空間。

通過使用ProcessExplorer，我們可以更清楚地看到堆溢出后的分頁池內(nèi)存分配情況，如圖五。

圖五 分頁池的內(nèi)存分配布局

圖六為堆溢出后的內(nèi)存頁的布局情況。我們利用該漏洞導致了SnxN緩沖區(qū)的溢出，并損壞了相鄰對象。

圖六 堆溢出#3

私有命名空間不僅可以使攻擊者控制分頁池大小，而且可以通過重寫NAMESPACE_DESCRIPTOR結構體的LIST_ENTRY字段中的指針來控制執(zhí)行情況。該字段將NAMESPACE_DESCRIPTOR結構體鏈接到系統(tǒng)中所有可用私有命名空間的列表。

假定我們已經(jīng)成功損壞了特定私有命名空間的NAMESPACE_DESCRIPTOR結構體的LIST_ENTRY字段。

圖七 不太安全的Unlinking功能（Win 7 SP1）

但是在Windows 8及更高版本中，由于安全的LIST_ENTRY結構體的使用，該方法并不能奏效。

圖八 安全的Unlinking功能（Win 8.1）

圖九為私有命名空間的目錄對象的損壞前后對比?？梢钥吹剑琋AMESPACE_DESCRIPTOR結構體的LIST_ENTRY字段已經(jīng)使用用戶空間地址（0×41414141）成功重寫。

圖九 目錄對象的損壞前后對比

控制EIP

成功損壞目錄對象后，接下來就是控制漏洞的執(zhí)行了。使用write-what-where條件重寫HalDispatchTable的函數(shù)指針，尤其是存儲在HalDispatchTable+sizeof(ULONG_PTR)這的hal!HaliQuerySystemInformation函數(shù)，然后通過調(diào)用ntdll!NtQueryIntervalProfile將漏洞執(zhí)行重定向到我們自己的負載。

函數(shù)調(diào)用序列為ntdll!NtQueryIntervalProfileà nt!NtQueryIntervalProfile à nt!KeQueryIntervalProfileà call   [nt!HalDispatchTable+sizeof(ULONG_PTR)](0×41414141)。

目前我們可以做到的是重寫內(nèi)核地址空間中的任意指針，并通過劫持攻擊控制EIP。但是這是遠遠不夠的。

write-what-where條件在斷開私有命名空間和系統(tǒng)中可用私有命名空間的連接時發(fā)生，也就是我們在關閉處理器或者使用特定私有命名空間中的目錄對象時。可以通過調(diào)用ClosePrivateNamespace或CloseHandle來實現(xiàn)該過程。

需要注意的是，為了堆溢出的發(fā)生，分頁池的數(shù)據(jù)塊頭已經(jīng)損壞，一旦釋放數(shù)據(jù)塊頭中的任意對象，都會觸發(fā)SoD，因為內(nèi)核會對比之前對象的實際大小和釋放的數(shù)據(jù)大小。

我們可以通過隔離這兩個階段來避開這個問題。我們是通過調(diào)用ZwDeletePrivateNameSpace而觸發(fā)的what-where條件，這會導致連接斷開，但是并不是釋放對象內(nèi)存。我們可以在post-exploitation清理階段重新保存LIST_ENTRY字段。

最后，我們可以安全地修復損壞的目錄對象，和NAMESPACE_DESCRIPTOR結構體，以保證系統(tǒng)不會報錯。

廠商修復

圖十 存在漏洞的函數(shù)

圖十一 修復的函數(shù)

由圖可以發(fā)現(xiàn)，修復的函數(shù)中添加了一個調(diào)用子程序的call sub_C161C指令，它的目的是驗證復制到固定大小的內(nèi)存中的數(shù)據(jù)大小，如果大小不合適，程序會調(diào)用ExAllocatePoolWithTag函數(shù)重新分配一個合適的空間，可以安全地保存數(shù)據(jù)。

*原文地址：nettitude，F(xiàn)B小編vul_wish編譯，轉載請注明來自FreeBuf黑客與極客（FreeBuf.COM）