cssembly · 2015/04/21 9:58

MS15-035是Microsoft Graphics 組件處理增強(qiáng)型圖元文件 (EMF) 的漏洞，可能允許遠(yuǎn)程執(zhí)行代碼。

通過補(bǔ)丁比對，可以看到主要是修補(bǔ)了一些可能存在整形溢出的位置，但是這些位置，我嘗試了很多方法都無法執(zhí)行到。

但是

#!c++ int __thiscall MRSETDIBITSTODEVICE::bPlay(EMRSETDIBITSTODEVICE *this, HDC hdc, struct tagHANDLETABLE *a3, unsigned int a4) 復(fù)制代碼

的修補(bǔ)是個(gè)例，補(bǔ)丁前的代碼如下：

打補(bǔ)丁后，代碼如下：

顯然補(bǔ)丁后的代碼對LocalAlloc分配的內(nèi)存空間的最小值進(jìn)行了限制，而打補(bǔ)丁之前并沒有限制，因此猜測這里可能存在一個(gè)緩沖區(qū)越界寫入問題。

通過分析函數(shù)調(diào)用鏈，可以找到MRSETDIBITSTODEVICE::bPlay被PlayEnhMetaFileRecord調(diào)用。PlayEnhMetaFileRecord根據(jù)EMF文件中元文件塊類型調(diào)用不同的解析函數(shù)。09年的文章《New EMF gdiplus.dll crash not exploitable for code execution》描述的EMF漏洞CVE-2009-1217也進(jìn)一步確認(rèn)了explorer進(jìn)程就是通過PlayEnhMetaFileRecord解析EMF文件的元文件塊的。

下面簡要介紹一下EMF文件的結(jié)構(gòu)，EMF文件由可變大小的元文件塊組成。每個(gè)元文件塊都是一個(gè)可變長度的ENHMETARECORD結(jié)構(gòu)，結(jié)構(gòu)如下。

#!c++ typedef struct tagENHMETARECORD {DWORD iType;DWORD nSize;DWORD dParm[1]; } ENHMETARECORD, *PENHMETARECORD; 復(fù)制代碼

SDK中定義了不同的iType類型，如下所示。

根據(jù)iType類型的不同，dParm是不同的結(jié)構(gòu)，EMR_SETDIBITSTODEVICE對應(yīng)的結(jié)構(gòu)是EMRSETDIBITSTODEVICE。

#!c++ typedef struct tagEMR {DWORD iType; // Enhanced metafile record typeDWORD nSize; // Length of the record in bytes.// This must be a multiple of 4. } EMR, *PEMR;typedef struct tagEMRSETDIBITSTODEVICE {EMR emr;RECTL rclBounds; // Inclusive-inclusive bounds in device unitsLONG xDest;LONG yDest;LONG xSrc;LONG ySrc;LONG cxSrc;LONG cySrc;DWORD offBmiSrc; // Offset to the source BITMAPINFO structureDWORD cbBmiSrc; // Size of the source BITMAPINFO structureDWORD offBitsSrc; // Offset to the source bitmap bitsDWORD cbBitsSrc; // Size of the source bitmap bitsDWORD iUsageSrc; // Source bitmap info color table usageDWORD iStartScan;DWORD cScans; } EMRSETDIBITSTODEVICE, *PEMRSETDIBITSTODEVICE;對于MRSETDIBITSTODEVICE::bPlay函數(shù)，其第一個(gè)參數(shù)為EMRSETDIBITSTODEVICE。為了驗(yàn)證猜想的正確性，通過程序生成一個(gè)小的emf文件，對其中的iType進(jìn)行修改，以便其執(zhí)行到MRSETDIBITSTODEVICE::bPlay函數(shù)，將0x54（EMR_EXTTEXTOUTW）修改為0x50（EMR_SETDIBITSTODEVICE） 復(fù)制代碼

。

#!c++ HDC hEmf = CreateEnhMetaFile( 0 , "1.emf" , NULL , NULL ); RECT rect; rect.top = 0 ; rect.left = 0 ; rect.bottom = 20; rect.right = 200;char szStr[] = "WSAWSAW"; ExtTextOut( hEmf , 0 , 0 , ETO_OPAQUE , &rect , szStr , sizeof(szStr) , NULL ); CloseEnhMetaFile(hEmf); DeleteObject(hEmf); 復(fù)制代碼

由于我在Win7下，瀏覽存放EMF文件的目錄并沒有觸發(fā)EMF文件的解析，因此通過mspaint.exe加載1.emf文件，執(zhí)行到

#!c++ int __thiscall MRSETDIBITSTODEVICE::bPlay(EMRSETDIBITSTODEVICE *this, HDC hdc, struct tagHANDLETABLE *a3, unsigned int a4) 復(fù)制代碼

函數(shù)時(shí)，可以看到ecx指向的數(shù)據(jù)與文件中的數(shù)據(jù)一致。

為了實(shí)現(xiàn)之前的猜想，實(shí)現(xiàn)越界寫操作，假定在((_DWORD *)v8 + 5) = v4->cbBitsSrc處實(shí)現(xiàn)了越界寫，這就要求v4->cbBmiSrc小于（64）。

由于MRSETDIBITSTODEVICE::bCheckRecord實(shí)現(xiàn)了對EMRSETDIBITSTODEVICE結(jié)構(gòu)的合法性檢查。函數(shù)如下。

根據(jù)檢查的內(nèi)容，對emf文件進(jìn)行修改，使其滿足MRSETDIBITSTODEVICE::bCheckRecord檢查的各項(xiàng)條件，同時(shí)使v4->cbBmiSrc小于（6*4），最終得到如下文件內(nèi)容。

用mspaint.exe加載emf文件，通過windbg可以觀察到所有的檢查都被繞過，同時(shí)LocalAlloc分配的內(nèi)存大小為2。

之后的((_DWORD *)v8 + 2) = v9與((_DWORD *)v8 + 5) = v4->cbBitsSrc都將實(shí)現(xiàn)緩沖區(qū)越界寫入操作。

如果可以通過腳本在瀏覽器上顯示emf文件，則有可能利用該漏洞實(shí)現(xiàn)遠(yuǎn)程代碼執(zhí)行。另外值得一提的是補(bǔ)丁中修補(bǔ)的其他如MF16_*的函數(shù)，這些函數(shù)的調(diào)用點(diǎn)都存在如下的代碼段。這是對HDC的類型進(jìn)行驗(yàn)證，只有類型是0x660000時(shí)，才會(huì)執(zhí)行這些函數(shù)，而我只在調(diào)用CreateMetaFile后才得到了類型是0x660000的HDC，屏幕上顯示時(shí)使用的HDC類型為0x10000。當(dāng)HDC類型是0x660000時(shí)，調(diào)用PlayEnhMetaFile，最終不會(huì)執(zhí)行PlayEnhMetaFileRecord。

總結(jié)

以上是生活随笔為你收集整理的MS15-035 EMF文件处理漏洞分析与POC构造的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。