MS15-035是Microsoft Graphics 組件處理增強型圖元文件 (EMF) 的漏洞，可能允許遠程執行代碼。
通過補丁比對，可以看到主要是修補了一些可能存在整形溢出的位置，但是這些位置，我嘗試了很多方法都無法執行到。
但是
#!c++
int __thiscall MRSETDIBITSTODEVICE::bPlay(EMRSETDIBITSTODEVICE *this, HDC hdc, struct tagHANDLETABLE *a3, unsigned int a4)
的修補是個例，補丁前的代碼如下：
打補丁后，代碼如下：
顯然補丁后的代碼對LocalAlloc分配的內存空間的最小值進行了限制，而打補丁之前并沒有限制，因此猜測這里可能存在一個緩沖區越界寫入問題。
通過分析函數調用鏈，可以找到MRSETDIBITSTODEVICE::bPlay被PlayEnhMetaFileRecord調用。PlayEnhMetaFileRecord根據EMF文件中元文件塊類型調用不同的解析函數。09年的文章《New EMF gdiplus.dll crash not exploitable for code execution》描述的EMF漏洞CVE-2009-1217也進一步確認了explorer進程就是通過PlayEnhMetaFileRecord解析EMF文件的元文件塊的。
下面簡要介紹一下EMF文件的結構，EMF文件由可變大小的元文件塊組成。每個元文件塊都是一個可變長度的ENHMETARECORD結構，結構如下。
#!c++
typedef struct tagENHMETARECORD {
DWORD iType;
DWORD nSize;
DWORD dParm[1];
} ENHMETARECORD, *PENHMETARECORD;
SDK中定義了不同的iType類型，如下所示。
根據iType類型的不同，dParm是不同的結構，EMR_SETDIBITSTODEVICE對應的結構是EMRSETDIBITSTODEVICE。
#!c++
typedef struct tagEMR
{
DWORD iType; // Enhanced metafile record type
DWORD 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 units
LONG xDest;
LONG yDest;
LONG xSrc;
LONG ySrc;
LONG cxSrc;
LONG cySrc;
DWORD offBmiSrc; // Offset to the source BITMAPINFO structure
DWORD cbBmiSrc; // Size of the source BITMAPINFO structure
DWORD offBitsSrc; // Offset to the source bitmap bits
DWORD cbBitsSrc; // Size of the source bitmap bits
DWORD iUsageSrc; // Source bitmap info color table usage
DWORD iStartScan;
DWORD cScans;
} EMRSETDIBITSTODEVICE, *PEMRSETDIBITSTODEVICE;
對于MRSETDIBITSTODEVICE::bPlay函數，其第一個參數為EMRSETDIBITSTODEVICE。為了驗證猜想的正確性，通過程序生成一個小的emf文件，對其中的iType進行修改，以便其執行到MRSETDIBITSTODEVICE::bPlay函數，將0x54（EMR_EXTTEXTOUTW）修改為0x50（EMR_SETDIBITSTODEVICE）
。
#!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);
由于我在Win7下，瀏覽存放EMF文件的目錄并沒有觸發EMF文件的解析，因此通過mspaint.exe加載1.emf文件，執行到
#!c++
int __thiscall MRSETDIBITSTODEVICE::bPlay(EMRSETDIBITSTODEVICE *this, HDC hdc, struct tagHANDLETABLE *a3, unsigned int a4)
函數時，可以看到ecx指向的數據與文件中的數據一致。
為了實現之前的猜想，實現越界寫操作，假定在((_DWORD *)v8 + 5) = v4->cbBitsSrc處實現了越界寫，這就要求v4->cbBmiSrc小于（64）。
由于MRSETDIBITSTODEVICE::bCheckRecord實現了對EMRSETDIBITSTODEVICE結構的合法性檢查。函數如下。
根據檢查的內容，對emf文件進行修改，使其滿足MRSETDIBITSTODEVICE::bCheckRecord檢查的各項條件，同時使v4->cbBmiSrc小于（6*4），最終得到如下文件內容。
用mspaint.exe加載emf文件，通過windbg可以觀察到所有的檢查都被繞過，同時LocalAlloc分配的內存大小為2。
之后的((_DWORD *)v8 + 2) = v9與((_DWORD *)v8 + 5) = v4->cbBitsSrc都將實現緩沖區越界寫入操作。
如果可以通過腳本在瀏覽器上顯示emf文件，則有可能利用該漏洞實現遠程代碼執行。另外值得一提的是補丁中修補的其他如MF16_*的函數，這些函數的調用點都存在如下的代碼段。這是對HDC的類型進行驗證，只有類型是0x660000時，才會執行這些函數，而我只在調用CreateMetaFile后才得到了類型是0x660000的HDC，屏幕上顯示時使用的HDC類型為0x10000。當HDC類型是0x660000時，調用PlayEnhMetaFile，最終不會執行PlayEnhMetaFileRecord。
