一、前言
在我之前發布的關于Yahoobleed #1（YB1）的一篇文章中，我們了解到如何利用未初始化漏洞獲取其他用戶的私密圖像信息。當時泄露的內存數據受制于JPEG圖像的壓縮機制，這種限制對某個圖像大盜來說不成問題，然而如果我們想要竊取其他類型的內存內容，已泄露的這些數據仍稍顯不足。
在這篇文章中，我會向大家介紹Yahoo!縮略圖服務器上存在的另一個滴血（bleed）類的漏洞，我們可以將這個稱之為Yahoobleed #2（YB2）。我們可以利用這個JPEG壓縮缺陷（現在這個缺陷依然存在）提取原始的內存字節。結合“strings”工具的使用，我們還可以發現更多驚喜。
Yahoo!通過棄用ImageMagic的方式，在修復YB1漏洞的同時也修復了YB2漏洞。大家可以參考我之前的一篇文章，通過Yahoo!的回復進一步了解漏洞的修復細節。
二、可視化
當我們觸發該漏洞時，Yahoo!服務器返回JPEG圖片上會出現某些噪點。如上圖所示，漏洞觸發后，Yahoo!服務器返回了某張JPEG圖片，將圖片的某個64x4區域轉化為png?www.myhack58.com格式（即無損格式），放大后可以看到某些噪點，如上圖所示。
這張圖片有許多有趣的地方值得注意，就現在而言，我們可以觀察到的是，圖片的頂部存在幾個指針圖像。我曾在Project Zero上發表過有關指針可視化的一篇文章，如果你對這篇文章有所了解，你可以在各種內存泄露場景中發現這類指針的存在。至少對于x86_64架構的Linux來說，該系統中的指針通常都包含一個0x00007f的前綴。這類指針的包含幾個特點，如：
1、使用相同的對齊方式重復類似的結構（64位系統上使用8字節對齊）；
2、在指針塊中，白色垂直條紋指向的是被對齊的最重要的字節，表示的是0x00（需要注意的是，由于輸入文件的特殊格式，所泄露的字節實際上經過了取反處理）；
3、在指針塊中，緊挨其后的黑色垂直條紋所代表的含義是某行的7個比特的值被設置為0x7f。
4、在指針塊中，緊挨其后的白色垂直細長條紋所代表的含義是該行的1個比特的值沒有被設置為0x7f。
但我們還是會遇到JPEG壓縮算法，這會不會對逐字節數據提取造成困難？我們會慢慢揭開這個謎題。
三、漏洞分析
我們不知道Yahoo!所使用的ImageMagic是否是最新版本，因此我們開始尋找相關的漏洞是否存在。我們已經知道Yahoo!支持RLE格式，之前我在一篇文章中介紹了如何使用某個技巧挖掘Box.com的內存損壞漏洞，也許我們可以使用相同的技巧對Yahoo!進行測試。
非常有趣的是，漏洞利用文件并不會導致任何文件崩潰，但服務器依然渲染了所有的測試文件，而最新版本的ImageMagic完全不會渲染這些文件。經過一番思考，我認為最有可能的解釋就是，Yahoo!所用的ImageMagic的確是存在漏洞的老版本，但根據我們對YB1漏洞的分析，Yahoo!使用了不一樣的堆設置，受對齊方式影響，我們的堆越界訪問測試用例無法在Yahoo!上生效。
為了驗證這個假設，我們構造了一個堆越界寫RLE文件，足以覆蓋堆中的某一小塊數據（64字節大小，大約會有16個字節被覆蓋），并將該文件上傳到Yahoo!上。訪問縮略圖URL后，服務器會較為穩定地（以大約50%左右的概率）返回如下結果：
這個結果看上去像是一個非常明顯的后端錯誤，我們猜測它最有可能是一個SIGSEGV錯誤，這個錯誤與已有兩年歷史的RLE內存損壞問題有關。
但是我們今天的目標并不是如何利用這個RCE內存損壞錯誤，雖然這個過程肯定非常有趣。我們的目標是通過滴血攻擊來提取數據�，F在，我們手上擁有的是一個已有2.5歲年齡的ImageMagick，對于這個版本的ImageMagick而言，肯定有許多漏洞已經被修復了。經過一番搜索，我們找到了一個候選漏洞：一個已有2年以上歷史的、已經在SUN解碼器中修復的越界漏洞。在這個漏洞的修復代碼中，開發者似乎對長度做了相關檢查，同時更加徹底地應用長度檢查過程，使其能夠將色深（bit depth）為1的圖像包含在內。讓我們稍微研究一下沒有打上補丁的代碼，并且深入跟蹤程序對色深為1的圖片的解碼路徑，我們可以發現如下代碼（位于coders/sun.c中）：
sun_info.width=ReadBlobMSBLong(image);
sun_info.height=ReadBlobMSBLong(image);
sun_info.depth=ReadBlobMSBLong(image);
sun_info.length=ReadBlobMSBLong(image);
[...]
number_pixels=(MagickSizeType) image->columns*image->rows;
if ((sun_info.type != RT_ENCODED) && (sun_info.depth >= 8) &&
((number_pixels*((sun_info.depth+7)/8)) > sun_info.length))
ThrowReaderException(CorruptImageError,"ImproperImageHeader");
bytes_per_line=sun_info.width*sun_info.depth;
sun_data=(unsigned char *) AcquireQuantumMemory((size_t) sun_info.length,
sizeof(*sun_data));
[...]
count=(ssize_t) ReadBlob(image,sun_info.length,sun_data);
if (count != (ssize_t) sun_info.length)
ThrowReaderException(CorruptImageError,"UnableToReadImageData");
sun_pixels=sun_data;
bytes_per_line=0;
[...]
p=sun_pixels;
if (sun_info.depth == 1)
for (y=0; y rows; y++)
{
q=QueueAuthenticPixels(image,0,y,image->columns,1,exception);
if (q == (Quantum *) NULL) break;
for (x=0; x columns-7); x+=8)
{
for (bit=7; bit >= 0; bit--)
{
SetPixelIndex(image,(Quantum) ((*p) & (0x01
q);
q+=GetPixelChannels(image);
}
p++;
}
因此，我們發現代碼在處理色深為1的圖像時存在一個非常明顯的問題：
1、假設該圖片的屬性為：width（寬度）=256, height（高度）=256, depth（色深）=1, length（長度）=8；
2、色深為1的圖像會導致與sun_info.length對比的number_pixels的檢查過程被繞過；
3、sun_data所分配的緩沖區大小為8字節，而程序從輸入文件中讀取了這8個字節；
4、然后程序按每個像素1個比特的方式對圖片進行解碼。在這個過程中，sun_data總共需要(256*256)/8 == 8192個字節，但只有8個字節可用；
5、然后就出現大量的越界讀取問題；程序實際上是在一片越界內存中對圖片進行渲染。
四、漏洞利用
漏洞利用文件只有40個字節，因此我們可以在十六進制編輯器中觀察這個圖片的每個字節的含義：
59 A6 6A 95: 頭部
00 00 01 00 00 00 01 00: 圖片大小256 x 256
00 00 00 01: 圖片色深：每像素1比特
00 00 00 08: 圖片數據長度為8
00 00 00 01: 圖片類型為1：標準圖片
00 00 00 00 00 00 00 00: map類型為空，長度為0
41 41 41 41 41 41 41 41: 8字節的圖片數據
對于這個漏洞利用文件，我們可以操縱的最為有趣的一個變量就是圖片數據長度（image data length）變量。只要我們將其大小控制在(256 * 256) / 8以內，我們就能復現越界讀取漏洞。但越界讀取從哪個位置開始呢？它會在圖片數據分配緩沖區的末尾開始。通過改變圖片數據的大小，我們最終有可能操縱堆中不同的相對地址（也許這些地址與緩沖區的開始或結束位置在距離上關系更為密切）。這樣一來我們有可能能夠讀取某些有趣的數據。
五、信息提取
顯然我們可以利用這個漏洞來提取信息，這也是這個漏洞真正有價值的地方所在。正如可視化部分所描述的內容，我們可以通過一個JPEG壓縮文件來嘗試提取信息。事實上我們可以通過ImageMagick獲得一張JPEG灰度圖像，因為前面每像素1比特的漏洞利用文件會生成一個黑白相間的圖形。我們可以利用JPEG灰度圖片較好地實現信息提取。人們之所以設計JPEG壓縮算法，主要是想欺騙人眼對圖片的直觀感知。相對比真實的顏色而言，人類視覺對顏色的亮度更為敏感，因此在壓縮算法中，顏色數據通常會比亮度數據丟失的信息更多（我們主要是通過YCbCr顏色空間實現這一點）。而JPEG灰度圖像中只有亮度數據存在。
回頭看看用于信息提取的那張JPEG圖像，我們仍然會遇到JPEG壓縮算法。我們會被這個困難所阻攔嗎？答案是否定的。因為我們的漏洞利用圖片是一張每像素1比特（黑色或白色）的圖片，因此我們只需要在信息提取的JPEG文件中精確控制每個像素的1比特信息熵即可。雖然某些白色像素實際上是有點淺灰色而不是全白色，且某些黑色像素實際上是有點深灰色而不是全黑色，但每個像素仍然非常接近于黑色或者白色。我當然沒有經過嚴密的數學計算，但事實上，對于Yahoo!服務器所使用的JPEG壓縮算法而言，每個像素的確包含1比特的信息熵。根據我的統計，與白色偏差最大的那個像素顏色大約為85%的白色（即非常淺的灰色），而信息丟失的閾值當然更低，可以達到50%或者以下。
我們可以嘗試從JPEG文件中恢復原始的字節，只需要使用如下的ImageMagick轉換命令即可：
convert yahoo_file.jpg -threshold 50% -depth 1 -negate out.gray
對于本文開頭的那個JPEG文件而言，恢復出來的原始內存字節如下所示：
0000000 d0 f0 75 9b 83 7f 00 00 50 33 76 9b 83 7f 00 00
0000020 31 00 00 00 00 00 00 00 2c 00 00 00 00 00 00 00
從中我們可以看到兩個指針：0x00007f839b75f0d0以及0x00007f839b763350。
六、字符串及密鑰
因此，現在我們有了一個在字節數據上相當可靠的信息提取方法，我們可以從Yahoo!縮略圖服務器上發現哪些有趣的字符串嗎？我們找到了許多信息量很大的字符串，我們用“redacted”替換了其中敏感的信息：
SSLCOOKIE: SSL=v=1&s=redacted&kv=0
Yahoo-App-Auth: v=1;a=yahoo.mobstor.client.mailtsusm2.prod;h=10.210.245.245;t=redacted;k=4;s=redacted
https://dl-mail.ymail.com/ws/download/mailboxes/@.id==redacted/messages/@.id==redacted/content/parts/@.id==2/raw?appid=getattachment&token=redacted&ymreqid=redacted
是的，結果看起來非常嚴重。
除了會話密鑰等有趣的字符串之外，我們還能看到其他信息嗎？是的，我們可以通過某些路徑、錯誤信息以及版本字符串發現服務器的確在使用ImageMagick，而且版本非常老：/usr/lib64/ImageMagick-6.8.9/modules-Q16/coders/sun.so
ImageMagick 6.8.9-6 Q16 x86_64 2014-07-25 http://www.myhack58.com
unrecognized PerlMagick method
顯然，這些字符串可以作為這個漏洞的佐證，同時我們還可以注意到字符串中涉及到PerlMagick。我對PerlMagick并不熟悉，可能PerlMagick是用來實現進程中的ImageMagick，這也是為什么我們的越界圖像數據能夠讀取這么多有趣信息的原因所在。
七、總結
這個漏洞非常有趣，我們發現服務器上存在內存泄露漏洞，可以將每個經過JPEG壓縮的像素的少量數據編碼后返回給我們，因此我們能夠較為穩定地重新構造原始的字節，還原服務器所泄露的內存數據。
在已啟用的解碼器中，不加限制地使用老版本的ImageMagick是一件非常危險的事情，通過棄用ImageMagick，Yahoo!應該已經修復了這些問題。
| 
