[[347297]]

一、概述

圖像解析和渲染是任何現(xiàn)代操作系統(tǒng)（OS）的基礎(chǔ)功能。同時(shí)，圖像解析也是一個(gè)易于訪(fǎng)問(wèn)的攻擊面，這一功能可以導(dǎo)致遠(yuǎn)程代碼執(zhí)行或信息泄露風(fēng)險(xiǎn)，對(duì)攻擊者來(lái)說(shuō)非常有價(jià)值。在這一系列文章中，我將回顧Windows操作系統(tǒng)內(nèi)置的圖像解析器和相關(guān)文件格式，特別關(guān)注構(gòu)建工具、尋找語(yǔ)料庫(kù)（Corpus）以及通過(guò)模糊測(cè)試（Fuzzing）發(fā)現(xiàn)漏洞的過(guò)程。在第一部分中，我們重點(diǎn)分析顏色配置文件。該文件并不是圖像格式本身，而是規(guī)則嵌入在圖像中的顏色。

二、ICC顏色配置文件分析

在維基百科上，提供了對(duì)ICC顏色配置文件的定義：“在顏色管理過(guò)程中，根據(jù)國(guó)際顏色協(xié)會(huì)（ICC）發(fā)布的標(biāo)準(zhǔn)，ICC配置文件是一組定義顏色輸入輸出設(shè)備以及顏色空間的數(shù)據(jù)。配置文件通過(guò)定義設(shè)備源或目標(biāo)顏色空間與配置文件連接空間（PCS）之間的映射，描述特定設(shè)備的顏色屬性或預(yù)覽要求。這里的PCS可以是CIELAB (L*a*b*)，或者是CIEXYZ?？梢允褂枚x插值（Interpolation）的表格來(lái)指定映射，也可以通過(guò)一系列參數(shù)進(jìn)行轉(zhuǎn)換。

簡(jiǎn)而言之，ICC顏色配置文件是一個(gè)二進(jìn)制文件，該文件會(huì)嵌入到圖像中，并在ICC支持的軟件處理圖像時(shí)進(jìn)行解析。

三、ICC規(guī)范

ICC規(guī)范大概有100頁(yè)，相對(duì)比較容易瀏覽。通讀規(guī)范可以更好地理解文件格式，不同類(lèi)型的顏色配置文件以及顏色轉(zhuǎn)換背后的數(shù)學(xué)原理。此外，了解文件格式的內(nèi)部結(jié)構(gòu)可以為我們提供信息，以便更好地優(yōu)化模糊測(cè)試、選擇良好的語(yǔ)料庫(kù)以及準(zhǔn)備模糊測(cè)試的字典。

四、關(guān)于Windows顏色管理

從Windows 95開(kāi)始，發(fā)布了圖像顏色管理（ICM）的1.0版本，從Windows 98以后開(kāi)始發(fā)布2.0版本。從Windows Vista開(kāi)始，對(duì)Windows色彩系統(tǒng)（WCS）1.0版本進(jìn)行了大幅改動(dòng)。ICC顏色配置文件是二進(jìn)制文件，而WCS顏色配置文件則使用XML作為其文件格式。在這篇文章中功能，我們專(zhuān)注于分析ICC顏色配置文件。

Microsoft曾發(fā)布過(guò)支持的Windows API的列表，其中就包含一些名稱(chēng)非常明顯的API，例如OpenColorProfile，我們可以看到它是在MSCMS.dll中實(shí)現(xiàn)的。這個(gè)DLL是通用入口點(diǎn)，支持加載Microsoft的顏色管理模塊（CMM）和第三方顏色管理模塊（例如Adobe的CMM）。Microsoft的CMM（即ICM）可以在system32目錄中找到，名稱(chēng)為ICM32.dll。

ICM32：

Windows的CMM是在Windows 95時(shí)代由第三方編寫(xiě)的，發(fā)展至今仍然或多或少地包含當(dāng)時(shí)的代碼，但已經(jīng)經(jīng)過(guò)了數(shù)十年來(lái)的安全修復(fù)。既然是如此古老的模塊，我們就有希望在其中發(fā)現(xiàn)新的漏洞。但是，這也是一個(gè)非常小的模塊，可能經(jīng)過(guò)了多輪審計(jì)和模糊測(cè)試，包括內(nèi)部產(chǎn)品安全團(tuán)隊(duì)和外部研究人員，這個(gè)事實(shí)在一定程度上降低了我們找到漏洞的希望。我們檢索近期發(fā)現(xiàn)的ICM32漏洞，可以發(fā)現(xiàn)Project Zero和ZDI的研究人員在2017-2018年期間發(fā)現(xiàn)了多個(gè)漏洞，但從2019年開(kāi)始就沒(méi)有找到更多的研究成果。

五、構(gòu)建工具

盡管在MSDN上有ICM API的列表，但我們需要找到Windows用于所有ICC相關(guān)操作的API序列。要查找API序列，一種方式是搜索Windows DLL和EXE的反匯編并尋找用到的顏色配置文件API，另一種方式是找到適用于開(kāi)源色彩管理系統(tǒng)（例如Little CMS，LCMS）的工具。使用這兩種方式，最終共同指向了很少的幾個(gè)API，這些API具有打開(kāi)顏色配置文件和創(chuàng)建顏色轉(zhuǎn)換的功能。

基于上述信息，我編寫(xiě)了一個(gè)簡(jiǎn)單的初始工具：

#include < stdio.h > 
#include < Windows.h > 
#include < Icm.h > 
#pragma comment(lib, "mscms.lib") 
int main(int argc, char** argv) 
{ 
    char dstProfilePath[] = "sRGB Color Space Profile.icm"; 
    tagPROFILE destinationProfile; 
    HPROFILE   hDstProfile = nullptr;   
    destinationProfile.dwType = PROFILE_FILENAME; 
    destinationProfile.pProfileData = dstProfilePath; 
    destinationProfile.cbDataSize = (strlen(dstProfilePath) + 1); 
    hDstProfile = OpenColorProfileA(&destinationProfile, PROFILE_READ, 
        FILE_SHARE_READ, OPEN_EXISTING); 
    if (nullptr == hDstProfile) 
    { 
        return -1; 
    }   
    tagPROFILE sourceProfile; 
    HPROFILE   hSrcProfile = nullptr; 
    HTRANSFORM hColorTransform = nullptr;     
    DWORD dwIntent[] = { INTENT_PERCEPTUAL, INTENT_PERCEPTUAL }; 
    HPROFILE hProfileList[2];   
    sourceProfile.dwType = PROFILE_FILENAME; 
    sourceProfile.pProfileData = argv[1]; 
    sourceProfile.cbDataSize = (strlen(argv[1]) + 1); 
    hSrcProfile = OpenColorProfileA(&sourceProfile, PROFILE_READ, 
        FILE_SHARE_READ, OPEN_EXISTING); 
    if (nullptr == hSrcProfile) 
    { 
        return -1; 
    }   
    hProfileList[0] = hSrcProfile; 
    hProfileList[1] = hDstProfile; 
    hColorTransform = CreateMultiProfileTransform( 
        hProfileList, 
        2, 
        dwIntent, 
        2, 
        USE_RELATIVE_COLORIMETRIC | BEST_MODE, 
        INDEX_DONT_CARE 
    ); 
    if (nullptr == hColorTransform) 
    { 
        return -1; 
    }   
    DeleteColorTransform(hColorTransform); 
    CloseColorProfile(hSrcProfile); 
    CloseColorProfile(hDstProfile); 
    return 0; 
} 

六、尋找語(yǔ)料庫(kù)和字典

在互聯(lián)網(wǎng)上，可以找到大量提供顏色配置文件的網(wǎng)站。顏色配置文件的另一個(gè)主要來(lái)源是圖像。有許多圖像文件都包含顏色配置文件，但需要一些工具將顏色配置文件轉(zhuǎn)儲(chǔ)到單獨(dú)的文件中。

簡(jiǎn)單瀏覽規(guī)范，我們還可以保證語(yǔ)料庫(kù)至少包含來(lái)自7個(gè)不同顏色配置文件的所有樣本。而將它與代碼覆蓋率信息結(jié)合，可以準(zhǔn)備第一套語(yǔ)料，用于模糊測(cè)試。

我們可以在梳理規(guī)范的過(guò)程中，創(chuàng)建唯一標(biāo)簽名稱(chēng)和對(duì)應(yīng)值的列表，從而準(zhǔn)備字典，幫助模糊工具查找其他代碼路徑。另外，還可以從LCMS這樣的開(kāi)源模糊測(cè)試嘗試過(guò)程中找到字典。

七、模糊測(cè)試

我使用16核主機(jī)對(duì)第一套語(yǔ)料進(jìn)行模糊處理，同時(shí)將來(lái)自MSCMS.dll和ICM32.dll的代碼覆蓋率信息作為我的模糊工具的反饋。在幾天后，開(kāi)始出現(xiàn)崩潰。

八、CVE-2020-1117：InitNamedColorProfileData中的堆溢出

在嘗試越界讀取時(shí)，icm32!SwapShortOffset中發(fā)生了以下崩潰：

0:000 > r 
rax=0000023690497000 rbx=0000000000000000 rcx=00000000000000ff 
rdx=000000000000ffff rsi=0000023690496f00 rdi=0000023690496fee 
rip=00007ffa46bf3790 rsp=000000c2a56ff5a8 rbp=0000000000000001 
 r8=0000000000000014  r9=0000023690497002 r10=0000000000000014 
r11=0000000000000014 r12=000000c2a56ff688 r13=0000023690492de0 
r14=000000000000000a r15=000000004c616220 
iopl=0         nv up ei ng nz ac pe cy 
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000293 
icm32!SwapShortOffset+0x10: 
00007ffa`46bf3790 0fb610          movzx   edx,byte ptr [rax] ds:00000236`90497000=?? 
  
0:000 > !heap -p -a @rax 
    address 0000023690497000 found in 
    _DPH_HEAP_ROOT @ 23690411000 
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize) 
                             23690412b60:      23690496f00              100 -      23690496000             2000 
    00007ffa51644807 ntdll!RtlDebugAllocateHeap+0x000000000000003f 
    00007ffa515f49d6 ntdll!RtlpAllocateHeap+0x0000000000077ae6 
    00007ffa5157babb ntdll!RtlpAllocateHeapInternal+0x00000000000001cb 
    00007ffa51479da0 msvcrt!malloc+0x0000000000000070 
    00007ffa46bf3805 icm32!SmartNewPtr+0x0000000000000011 
    00007ffa46bf37c8 icm32!SmartNewPtrClear+0x0000000000000014 
    00007ffa46c02d05 icm32!InitNamedColorProfileData+0x0000000000000085 
    00007ffa46bf6e39 icm32!Create_LH_ProfileSet+0x0000000000004e15 
    00007ffa46bf1973 icm32!PrepareCombiLUTs+0x0000000000000117 
    00007ffa46bf1814 icm32!CMMConcatInitPrivate+0x00000000000001f4 
    00007ffa46bf12a1 icm32!CWConcatColorWorld4MS+0x0000000000000075 
    00007ffa46bf11f4 icm32!CMCreateMultiProfileTransformInternal+0x00000000000000e8 
    00007ffa46bf1039 icm32!CMCreateMultiProfileTransform+0x0000000000000029 
    00007ffa48f16e6c mscms!CreateMultiProfileTransform+0x000000000000024c 
    00007ff774651191 ldr+0x0000000000001191 
    00007ff7746514b4 ldr+0x00000000000014b4 
    00007ffa505a7bd4 KERNEL32!BaseThreadInitThunk+0x0000000000000014 
    00007ffa515aced1 ntdll!RtlUserThreadStart+0x0000000000000021 

icm32!SwapShortOffset讀取無(wú)符號(hào)的短值，對(duì)其進(jìn)行bswap，并將它們存儲(chǔ)在相同的位置，這會(huì)導(dǎo)致讀寫(xiě)原語(yǔ)崩潰。

反編譯的SwapShortOffset：

unsigned __int16 *__fastcall SwapShortOffset(void *sourceBuff, unsigned int offset, unsigned int len) 
{ 
  unsigned __int16 *endBuff; // r9 
  unsigned __int16 *result; // rax 
  
  endBuff = (sourceBuff + len); 
  for ( result = (sourceBuff + offset); result < endBuff; ++result ) 
    *result = _byteswap_ushort(*result);        // read, bswap and write 
  return result; 
} 

崩潰的函數(shù)icm32!SwapShortOffset并不能立即指向?qū)е略搯?wèn)題的根本原因。為此，我們需要查看icm32!InitNamedColorProfileData。

反編譯的InitNamedColorProfileData：

__int64 __fastcall InitNamedColorProfileData(__int64 a1, void *hProfile, int a3, _DWORD *a4) 
{ 
  ... 
  ... 
  errCode = CMGetPartialProfileElement(hProfile, 'ncl2', 0, pBuffSize, 0i64);      // getting size of ncl2 element 
  if ( errCode ) 
    return errCode; 
  minSize = pBuffSize[0]; 
  if ( pBuffSize[0] < 0x55 ) 
    minSize = 0x55; 
  pBuffSize[0] = minSize; 
  outBuff = SmartNewPtrClear(minSize, &errCode);                                    // allocating the buffer for ncl2 
  ... 
  ... 
  errCode = CMGetPartialProfileElement(hProfile, 'ncl2', 0, pBuffSize, outBuff);    // reading ncl2 elements to buffer 
  if ( !errCode ) 
  { 
    ... 
    ... 
    totalSizeToRead = count * totalDeviceCoord; 
    if ( totalSizeToRead < 0xFFFFFFFFFFFFFFAEui64 && totalSizeToRead + 0x51 <= pBuffSize[0] )  // totalSizeToRead + 0x51 <= element size? 
    { 
      currPtr = outBuff + 0x54;            // wrong offset of 0x54 is used 
      ... 
      ... 
      do 
      {   
        SwapShortOffset((currPtr + 0x20), 0, 6u); 
        ... 
        --count; 
      }while(count) 

在這里，代碼嘗試讀取“ncl2”標(biāo)簽/元素，并從文件中獲取流的大小。一個(gè)緩沖區(qū)會(huì)被分配，并再次進(jìn)行相同的調(diào)用，以讀取元素ncl2的完整內(nèi)容。該緩沖區(qū)將被解析，以查找設(shè)備位置的計(jì)數(shù)和編號(hào)，并通過(guò)確保讀寫(xiě)操作位于緩沖區(qū)大小中來(lái)驗(yàn)證該值。其中存在一個(gè)漏洞，用于驗(yàn)證的偏移量（0x51）小于緩沖區(qū)指針的偏移量（0x54），該漏洞導(dǎo)致可以超過(guò)邊界讀寫(xiě)3個(gè)字節(jié)。

該漏洞的修復(fù)方法非常簡(jiǎn)單，將用于驗(yàn)證的偏移量修改為0x54即可，這也是Microsoft實(shí)際修復(fù)此漏洞的方式。

九、其他漏洞

在分析上面的漏洞時(shí)，我們發(fā)現(xiàn)過(guò)程中會(huì)使用到CMGetPartialProfileElement函數(shù)讀取大小、進(jìn)行分配和讀取內(nèi)容。而這種模式可能會(huì)引入漏洞，例如大小不受限制、整數(shù)溢出、導(dǎo)致偏移量增加等。我決定分析這個(gè)函數(shù)，并尋找ICM32.dll中是否存在這樣的實(shí)例。

最終發(fā)現(xiàn)有3個(gè)實(shí)例具有未經(jīng)檢查的偏移量訪(fǎng)問(wèn)，分別是：CMConvIndexToNameProfile、CMConvNameToIndexProfile和CMGetNamedProfileInfoProfile。所有這些函數(shù)都可以通過(guò)導(dǎo)出的、有詳細(xì)說(shuō)明的MSCMS函數(shù)進(jìn)行訪(fǎng)問(wèn)，分別是ConvertIndexToColorName、CMConvertColorNameToIndex和GetNamedProfileInfo。

反編譯后的CMConvIndexToNameProfile：

__int64 __fastcall CMConvIndexToNameProfile(HPROFILE hProfile, __int64 a2, __int64 a3, unsigned int a4) 
{ 
  ... 
  ... 
  errCode = CMGetPartialProfileElement(hProfile, 'ncl2', 0, pBuffSize, 0i64);    // read size 
  if ( !errCode ) 
  { 
    allocBuff = SmartNewPtr(pBuffSize[0], &errCode); 
    if ( !errCode ) 
    { 
      errCode = CMGetPartialProfileElement(hProfile, 'ncl2', 0, pBuffSize, allocBuff);    // read to buffer 
      if ( !errCode ) 
      { 
        SwapLongOffset((allocBuff + 12), 0, 4u);         // 12 > *pBuffSize ? 
        SwapLongOffset((allocBuff + 16), v12, v13); 

在CMConvIndexToNameProfile和其他兩個(gè)函數(shù)中，我們發(fā)現(xiàn)了漏洞，并沒(méi)有檢查ncl2元素的最小長(zhǎng)度，且偏移量12和16可以直接訪(fǎng)問(wèn)以進(jìn)行讀取和寫(xiě)入。那么如果allocBuffer的大小小于12，就可以實(shí)現(xiàn)對(duì)allocBuffer的越界讀寫(xiě)。

由于在Windows中沒(méi)有二進(jìn)制文件使用這些函數(shù)，因此Microsoft決定不會(huì)立即修復(fù)這三個(gè)漏洞。此外，我們也沒(méi)有找到使用這些API的任何Windows軟件或第三方軟件。

十、總結(jié)

在這一系列文章的第一部分中，我們對(duì)顏色配置文件進(jìn)行了深入分析，編寫(xiě)工具并成功找到了多個(gè)漏洞。請(qǐng)大家繼續(xù)關(guān)注第二部分，在第二部分中，我們將分析很少有人研究的一類(lèi)漏洞——內(nèi)存未初始化漏洞。

本文翻譯自：https://www.fireeye.com/blog/threat-research/2020/09/fuzzing-image-parsing-in-windows-color-profiles.html如若轉(zhuǎn)載，請(qǐng)注明原文地址。