Kate Li (Taiwan)的部落格

首頁

多年前修復了fastfat漏洞。。。

作者 sebastiani 時間 2020-04-05
all

在脆弱性研究和電腦安全方面,我們經常嚴格地處理無形的問題。然而,有時有形的攻擊向量可以在現實世界的攻擊中發揮重要作用。在很多情况下,USB記憶棒和相關設備在協助攻擊中起著共同的物理作用。從Stuxnet利用USB橋接air gap網絡到badubs,有許多例子值得注意。這就是為什麼本周微軟安全公告MS14-063在FastFat中的漏洞抓到了我們的eEye。這個漏洞最讓我們感興趣的是受影響的作業系統清單:服務器2003、Vista和服務器2008。為什麼不是Windows7?FastFat驅動程序在作業系統版本之間不應該有太大的變化。正是有了這種奇怪的預感,我們才開始調查修補過的檔案fastfat.sys。從Windows Server 2003r2開始。我們從Windows Server 2003r2和fastfat.sys版本5.2.3790.3959(未修補)與fastfat.sys版本5.2.3790.5425(修補)的二進位差异分析開始。在這兩個版本之間幾乎沒有變化,也沒有添加或删除函數。_fatcomonwrite()雖然是一個函數的怪物,但只包含兩個基本的塊變化。我們研究的第一個涉及ExAllocatePoolWithTag(),很可能是安全性更改。圖1-fatcomonwrite-pre-patchHere中的相關基本塊,在pre-patchHere中,我們正在檢查一個結構中的0x96位元組,如果它大於2,則執行分配。如果是這種情況,分配的大小由結構中的偏移量决定。讓我們看看修補程式後的情况。圖2-fatcomonwrite-post patchHere中的相關基本塊我們可以看到ExAllocatePoolWithTag()調用現在正在操作偏移量0x96處的位元組到該結構中。具體來說就是乘以24。很可能這是一個正在分配的結構的大小,這在預修補程式中被遺忘了。囙此,在預修補程式中對ExAllocatePoolWithTag生成的分配大小的假設似乎不正確,這可能會導致函數稍後出現緩衝區溢位。在www.google.com上的快速搜索顯示這個反彙編與write.c中的一些Windows 2000程式碼非常接近。圖3-google.com蒐索中相應的windows2000程式碼。囙此,Vcb->Bpb.Fats似乎是罪魁禍首。這裡Bpb是指Bios參數塊,它訪問的成員是Bpb-NumFATs。圖4-FAT BPB檔案-http://staff.washington.edu/dittrich/misc/fatgen103.pdfIn預先修補的服務器2003r2程式碼,在上面的Windows 2000程式碼中,如果BPB.Fats>2,則分配不會將BPB NumFATs乘以IO運行的大小。通過查看服務器2003r2修補程式中fatcomonwrite中的VAR_158(包含2個IO_運行結構的堆棧緩衝區),我們可以知道IO_運行結構是24位元組。我們可以看到VAR_的大小是48,囙此一個IO_運行必須是24。我們也可以在windbg中解决這個問題,或者通過補丁後分配將fats的數量乘以24得出結論。這是問題的根本原因,而且很酷,但是為什麼Windows 7不易受攻擊呢?讓我們看看來自Windows7的fastfat.sys版本6.1.7600.16385的_fatcomonwrite()函數。圖5-來自Windows7中FatCommonWrite的相關基本塊,這很奇怪。它似乎正在考慮訪問BPB_NumFATs成員(在內部結構中的偏移量略有不同)並在分配時考慮IO_RUN結構的大小。很可能這與MS14-063相同,只是此DLL上的修改日期在2009年的某個地方。也就是說,此漏洞已在較新的作業系統中修補,而較舊但仍受支持的作業系統仍然存在漏洞,這意味著多年來,Windows 2003、2008中已存在此漏洞,Vista和XP系統,而Windows 7和更高版本的系統不是偶然修復的,就是開發人員沒有花時間將修復程式移植到舊的、但仍受支持的作業系統中。