一個(gè)GIF表情搞死微信！最強(qiáng)技術(shù)分析在此

5月17日左右，微信群中出現(xiàn)了可使iOS版微信閃退的GIF表情。

5月26日傍晚，360安全研究員宋申雷對(duì)表示，微信知道這個(gè)漏洞兩周了，但是攔截策略依然不行，第一個(gè)crash出現(xiàn)時(shí)就對(duì)樣本做了hash 攔截，這都兩周了，改一個(gè)字節(jié)的版本都有多少個(gè)了。

此外，他還指出，現(xiàn)在不在原圖改字節(jié)了，直接把有漏洞的最后一幀構(gòu)造到任意的GIF中。

為了更好地促進(jìn)讀者了解其中的機(jī)制，360NirvanTeam對(duì)于此事件進(jìn)行了具體的技術(shù)分析。

一、背景情況

5月17日起，在各個(gè)微信群中流傳著一個(gè)天線寶寶的GIF表情。在iOS版的微信上，只要打開(kāi)了包含這個(gè)GIF表情的聊天窗口，就會(huì)造成微信閃退。

在進(jìn)行具體分析之前，對(duì)崩潰原因進(jìn)行了猜測(cè)：（1）iOS系統(tǒng)自帶GIF解析功能存在問(wèn)題；（2）微信自己實(shí)現(xiàn)GIF解析的功能，由于對(duì)輸入數(shù)據(jù)的校驗(yàn)不嚴(yán)格，導(dǎo)致異常。

經(jīng)過(guò)測(cè)試，發(fā)現(xiàn)iOS版QQ不受影響，因此可以排除iOS的GIF解析問(wèn)題。

二、原因分析

1、樣本精簡(jiǎn)

初始的GIF樣本有1MB之多，不利于定位引起問(wèn)題的具體數(shù)據(jù)，因此我們需要對(duì)樣本進(jìn)行精簡(jiǎn)。通過(guò)010 Editor打開(kāi)原始樣本GIF，利用GIF模板解析，發(fā)生解析異常，這就表示樣本GIF的格式存在問(wèn)題。

從模板解析的情況顯示，在38幀正常的圖片數(shù)據(jù)后，出現(xiàn)了異常的數(shù)據(jù)。如圖所示，因此我們將正常數(shù)據(jù)部分移除，僅保留異常數(shù)據(jù)，進(jìn)行下一步精簡(jiǎn)。

可以看到，剩余的異常數(shù)據(jù)的部分有10多萬(wàn)個(gè)，通過(guò)二分法的方式進(jìn)行測(cè)試和排除。具體就是，刪除一半后，測(cè)試另外一半是否可以導(dǎo)致崩潰。

如果崩潰了，說(shuō)明引起異常的數(shù)據(jù)在保留的一半中，反之則說(shuō)明在刪除的部分中。

經(jīng)過(guò)不斷的排除后，發(fā)現(xiàn)異常的數(shù)據(jù)就在下圖的紫色部分中。只要帶有GIF的圖像數(shù)據(jù)部分帶有這些異常數(shù)據(jù)，就會(huì)導(dǎo)致iOS微信閃退。

2、調(diào)試分析

經(jīng)過(guò)樣本精簡(jiǎn)，我們已經(jīng)發(fā)現(xiàn)了引起異常的數(shù)據(jù)位置。那么，現(xiàn)在就需要結(jié)合實(shí)際的調(diào)試，來(lái)確定實(shí)際引起異常的數(shù)據(jù)。

以iOS微信6.5.7版為例，崩潰發(fā)生時(shí)的調(diào)用棧如下，崩潰發(fā)生于微信內(nèi)部，說(shuō)明是微信自身的GIF解析功能存在問(wèn)題。

經(jīng)過(guò)對(duì)相關(guān)函數(shù)的逆向分析，最終確定了引起異常的數(shù)據(jù)。首先來(lái)觀察sub_100B6CBF0這個(gè)函數(shù)，對(duì)于GIF中的數(shù)據(jù)進(jìn)行循環(huán)查找，如果存在0x21和0xF9，那么當(dāng)前數(shù)據(jù)就表示是一個(gè)GraphicControlExtension結(jié)構(gòu)，并接著對(duì)GraphicControlExtension數(shù)據(jù)進(jìn)行解析。

如果當(dāng)前查找到的數(shù)據(jù)為0x2C，就表示搜索到了一個(gè)ImageDescriptor，跳出while循環(huán)，進(jìn)行實(shí)際圖片數(shù)據(jù)的解析。這里也就是異常數(shù)據(jù)的起始位置！

正常的幀數(shù)據(jù)的ImageDescriptor數(shù)據(jù)如下：

而引起異常的數(shù)據(jù)中，恰好存在0x2C這個(gè)關(guān)鍵的分隔符，導(dǎo)致下述紅框中的數(shù)據(jù)被解析成了一個(gè)ImageDescriptor?？梢钥吹?，ImageWidth屬性為0，ImageHeight屬性為0x100。

接下來(lái)，這部分異常的數(shù)據(jù)就會(huì)進(jìn)入sub_100B6CE90函數(shù)進(jìn)行解析。由于ImageWidth為0，導(dǎo)致與ImageHeight相乘后等于0，在new buffer時(shí)，傳入的大小參數(shù)為0，這是第一個(gè)問(wèn)題，但這并不會(huì)導(dǎo)致閃退，仍然可以分配一個(gè)很小的堆塊。

引起崩潰的代碼如下，在else block中，sub_100B6C4F0的作用沒(méi)有具體跟蹤，猜測(cè)是進(jìn)行l(wèi)zw解壓縮，并返回解壓縮后的數(shù)據(jù)長(zhǎng)度v21。

由于v10 = 0x0000010000000000，截?cái)喑蓇nsigned int后為0，這就導(dǎo)致 v10 – 1 – v21 為負(fù)數(shù)，作為memset第三個(gè)參數(shù)，相應(yīng)的unsigned int形式就是一個(gè)很大的正數(shù)。在memset時(shí)，就會(huì)導(dǎo)致崩潰，這是第二個(gè)問(wèn)題。

三、總結(jié)

這個(gè)問(wèn)題的根本原因是微信實(shí)現(xiàn)了自己的GIF解析功能，但由于對(duì)輸入數(shù)據(jù)的校驗(yàn)不嚴(yán)格，導(dǎo)致異常的數(shù)據(jù)被解析，引起崩潰。

在5月17日當(dāng)天，這個(gè)GIF開(kāi)始流傳后，微信似乎在服務(wù)器端做了屏蔽，使得這個(gè)GIF無(wú)法被正常接收，但我們只要隨便修改一下GIF中的任意一個(gè)字節(jié)，就能繞過(guò)這個(gè)屏蔽措施。

同時(shí)由于iOS應(yīng)用上架需要經(jīng)過(guò)蘋果審核，需要額外耗費(fèi)一定時(shí)間，這就使得這個(gè)Bug即使修復(fù)后，所有用戶也無(wú)法立刻更新。

目前最新的iOS微信6.5.8版本仍然存在崩潰的問(wèn)題。