CVE-2019-11933

Android版WhatsAppのバージョン2.19.291以前に影響するWhatsAppのメディアピッカーにおけるヒープ破損

背景

GIFファイルは、特定のバイトで区切られたセグメントに分割されます。

• Image (0x2C)
  • 画像セクションはGIFファイル内の単一フレームを記述し、高さ、幅、および圧縮された画像自体などの情報を含みます。GIFは複数のフレームを持つことができ、したがって複数の画像セクションを持ちます。
• Extension (0x21)
  • 拡張セクションには、画像を変更するために使用されるデータが含まれます。
• Terminate (0x3B)
  • GIFファイルの終端を示します。

ソースコードによると、renderFrameはDDGifSlurpを呼び出してGIFを解析し、getBitmapを呼び出してGIFを表示します。関数によってrasterBitsバッファが割り当てられ、そのサイズは現在処理中の画像の幅と高さを掛け合わせて計算されます。おそらくメモリと時間を節約するため、同じrasterBitsバッファがGIF内のすべてのフレーム/画像に使用されます。したがって、バッファはファイル内で最も大きな画像を格納できる必要があります。そのため、同じGIF内の別の画像セクションがより大きな画像（より多くのスペースを必要とする）を記述している場合、バッファはそれに応じて再割り当てされます。

脆弱性

DDGifSlurpはループ内でGIFファイルを解析し、ファイル内の各画像/フレームを処理し、終了レコードに遭遇すると終了します。DGifGetImageDescがGIF_ERRORを返すと (a)、早期終了 (switch case内で) となり、rasterBitsバッファを再割り当てするコードがスキップされます。DDGifSlurpの一部を以下に示します：

void DDGifSlurp(GifInfo *info, bool decode, bool exitAfterFrame) {
    ...
    do {
        ...
        switch (RecordType) {
            case IMAGE_DESC_RECORD_TYPE:
             
                if (DGifGetImageDesc(gifFilePtr, isInitialPass) == GIF_ERROR) {   <-- [a]
                    break;
                }
                ...
                if (decode) {
                    ...
                    const uint_fast32_t newRasterSize = gifFilePtr->Image.Width * gifFilePtr->Image.Height;
                    if (newRasterSize > info->rasterSize || widthOverflow > 0 || heightOverflow > 0) {
                        void *tmpRasterBits = reallocarray(info->rasterBits, newRasterSize, sizeof(GifPixelType));
                        ...
                    }
    }while (RecordType != TERMINATE_RECORD_TYPE);
}

以下の形式を持つGIF画像はクラッシュを引き起こします：

• 有効な画像 (10 x 10)
• 無効な画像記述子を持つ大きな画像 (10000 x 10000)

クラッシュに至る段階

1. 解析フェーズ
   1. 最初の画像 (小) を解析
   2. サイズ (小の高さ * 小の幅) のrasterBitsバッファを割り当て
   3. 2番目の画像 (大) を解析
   4. DGifSetupDecompress/DGifGetImageDescがGIF_ERRORを返す
   5. 再割り当てをスキップ
2. レンダリングフェーズ
   1. 最初の画像をレンダリング (成功)
   2. 2番目の画像をレンダリング (OOB)