Windows でのファジング画像解析、パート 3: RAW および HEIF

Windows イメージライブラリの自動テストにより、CVSS スコア 7.8 のゼロクリックコード実行を含む 37 のセキュリティ問題が明らかになりました。すべての脆弱性は、Mandiant による開示に続いて Microsoft によって修正されました。

Windows での画像解析の脆弱性に関する説明を続けると、Windows でサポートされている 2 つのファイルタイプ、RAW と High Efficiency Image File Format (HEIF) に注目します。

Windows XP 以降の Windows バージョンには、これらのコーデックがデフォルトで含まれているため、RAW ファイルはWindows Camera Codec Packでサポートされています。コーデックファイルは、system32 フォルダーにWindowsCodecsRaw.dllとして存在します。 RAW コーデックは Windows Imaging Component (WIC) 対応です。つまり、WIC を使用するプログラムは、コードを追加しなくても RAW 画像を読み込んでデコードできるはずです。これにより、Explorer でサムネイルとプレビューを表示できるようになり、Microsoft.Photos.exe でサポートされている RAW 画像を表示できるようになります。 WIC とコンポーネントオブジェクトモデル (COM) がファイル形式の検出と対応するコーデックの読み込みを処理するため、コーデックを WIC 対応にすることで、新しいファジングハーネスの作成を回避できました。これは、ファジングをすぐに開始するのに非常に便利でしたが、COM の動作方法が原因で、重いパフォーマンスの負担 (10 倍から 30 倍の速度低下) が伴いました。

このコーデックは、Canon、Casio、Epson、Fujifilm、Kodak、Konica Minolta、Leica、Nikon、Olympus、Panasonic、Pentax、Samsung、Sony、およびその他のさまざまなカメラモデルなど、複数のカメラメーカーの RAW ファイルをサポートしています。表面的には、サポートされているカメラモデルとメーカーの数を考えると、これは非常に魅力的な攻撃対象領域です。残念ながら、サポートされているファイル形式のほとんどは TIFF であるか、TIFF ファイル形式に基づいています。

RAW コーデックのファジングには、汎用の WIC ハーネスを使用し、 WindowsCodecsRaw.dllをコードカバレッジモジュールとして使用します。コーパスはさまざまな公共の場所から収集され、コードカバレッジの一部を犠牲にしてサイズを最小限に抑えました。これは、RAW ファイルのファイルサイズが大きいため必要です。

ファジングでは、Canon CR2 形式の RAW ファイルのライブラリの解析で 2 つの整数オーバーフローの脆弱性と、HEIF ファイルの解析で 35 の脆弱性を発見しました。このブログ投稿では、最も注目すべき調査結果の詳細を紹介します。

CVE-2020-16968

CVE-2020-16968 は、特別に細工された Canon CR2 ファイルの解析中にヒープオーバーフローを引き起こす整数オーバーフローです。

クラッシュの詳細を図 1 に示します。

0:000> r

rax=0000000009aee38e rbx=000000000000008e rcx=00000203b8ab0580

rdx=0000000000000d07 rsi=0000000000000d34 rdi=00000203b7998f20

rip=00007ffcbd26c4e2 rsp=000000c6b258e370 rbp=000000c6b258e470

r8=000000000000008e r9=0000000000000000 r10=00000203b7a2eff0

r11=00000000000006c0 r12=000000000000036e r13=000000000000bbbb

r14=0000000000000658 r15=0000000000000e0c

iopl=0 nv up ei pl nz na po nc

cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000206

WindowsCodecsRaw!CCanonSRawLoadRaw::lossless_jpeg_load_raw+0x1f2:

00007ffc`bd26c4e2 6644890c41 mov word ptr [rcx+rax*2],r9w ds:00000203`cc08cc9c=????

0:000> !heap -p -a @rcx

address 00000203b8ab0580 found in

_DPH_HEAP_ROOT @ 203a4231000

in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize)

203a4295270: 203b8ab0580 135cca80 - 203b8ab0000 135ce000

00007ffd065c73ab ntdll!RtlDebugAllocateHeap+0x000000000000003b

00007ffd064e9745 ntdll!RtlpAllocateHeap+0x00000000000000f5

00007ffd064e73d4 ntdll!RtlpAllocateHeapInternal+0x00000000000006d4

00007ffcbd0ffb6d WindowsCodecsRaw!POBitmapImageRep::init+0x00000000000001f1

00007ffcbd0ff926 WindowsCodecsRaw!POBitmapImageRep::POBitmapImageRep+0x00000000000000aa

00007ffcbd269f88 WindowsCodecsRaw!CCanonSRawLoadRaw::GetBitmapImage+0x00000000000000d8

00007ffcbd269ea3 WindowsCodecsRaw!CCanonSRawLoadRaw::GetBitmapImage+0x0000000000000023

00007ffcbd18e19b WindowsCodecsRaw!CCanon1DMK4ImageRep::GetBitmapImageFromFile+0x00000000000002bb

00007ffcbd10d635 WindowsCodecsRaw!CRawImageRep::GetBitmapImageRep+0x0000000000000055

00007ffcbd0fe4fe WindowsCodecsRaw!RawImageGetBitmap+0x000000000000005e

00007ffcbd0f4b9a WindowsCodecsRaw!FSixFrameDecode::EnsureRawBitmap+0x0000000000000076

00007ffcbd0f4de8 WindowsCodecsRaw!FSixFrameDecode::RunPipelineInternal+0x0000000000000068

00007ffcbd0f4d60 WindowsCodecsRaw!FSixFrameDecode::RunPipeline+0x0000000000000104

00007ffcbd0f664a WindowsCodecsRaw!FSixFrameDecode::CopyPixels+0x00000000000003ca

0:000> k

# Child-SP RetAddr Call Site

00 000000c6`b258e370 00007ffc`bd26a016 WindowsCodecsRaw!CCanonSRawLoadRaw::lossless_jpeg_load_raw+0x1f2

01 000000c6`b258e4d0 00007ffc`bd269ea3 WindowsCodecsRaw!CCanonSRawLoadRaw::GetBitmapImage+0x166

02 000000c6`b258e5c0 00007ffc`bd18e19b WindowsCodecsRaw!CCanonSRawLoadRaw::GetBitmapImage+0x23

03 000000c6`b258e610 00007ffc`bd10d635 WindowsCodecsRaw!CCanon1DMK4ImageRep::GetBitmapImageFromFile+0x2bb

04 000000c6`b258e7a0 00007ffc`bd0fe4fe WindowsCodecsRaw!CRawImageRep::GetBitmapImageRep+0x55

05 000000c6`b258e7d0 00007ffc`bd0f4b9a WindowsCodecsRaw!RawImageGetBitmap+0x5e

06 000000c6`b258e870 00007ffc`bd0f4de8 WindowsCodecsRaw!FSixFrameDecode::EnsureRawBitmap+0x76

07 000000c6`b258e8a0 00007ffc`bd0f4d60 WindowsCodecsRaw!FSixFrameDecode::RunPipelineInternal+0x68

08 000000c6`b258f030 00007ffc`bd0f664a WindowsCodecsRaw!FSixFrameDecode::RunPipeline+0x104

09 000000c6`b258f0d0 00007ffc`fc73ceb3 WindowsCodecsRaw!FSixFrameDecode::CopyPixels+0x3ca

図 1: RAW コーデックのクラッシュ

バグの根本原因は、図 2 のWindowsCodecsRaw!POBitmapImageRep::initでのオブジェクトの割り当てを調べることで見つけることができます。

void __fastcall POBitmapImageRep::init(

POBitmapImageRep *this,

unsigned int swidth,

unsigned int sheight,

...

)

{

...

unsigned int allocSize; // ebx

HANDLE ProcessHeap; // rax

LPVOID allocMem; // rax

...

// validations

if ( swidth > 0x10000

|| sheight > 0x10000

...)

{

ATL::AtlThrowImpl(0x80070057);

}

...

swidthX2 = swidth * two_2;

...

allocSize = swidthX2 * sheight; // integer overflow

ProcessHeap = GetProcessHeap();

allocMem = HeapAlloc(ProcessHeap, 0, allocSize);

*(this + 12) = allocMem;

...

}

図 2: 脆弱な機能

POBitmapImageRep::initは、カメラセンサーに関連付けられた複数の高さと幅を受け入れ、それらが受け入れる値の大まかな検証を行います。これらの値は画像ファイルから取得されるため、ユーザーが制御できます。この脆弱性は、最初の検証であっても、センサーの高さと幅の 32 ビットの乗算によって整数オーバーフローが発生し、ヒープメモリの割り当てが必要以上に小さくなる可能性があるという事実から発生します。さらに、 POBitmapImageRep::initは、メモリの割り当てに使用される汎用関数であり、さまざまなメーカーの複数の RAW ファイル形式で使用されています。異なるファイル形式も同じ脆弱性を引き起こす可能性が非常に高いです。

整数オーバーフローの原因となるサンプル値を図 3 に示します。

swidth = 0xbbc0;

sheight = 0xbbbb;

swidthX2 = swidth * 2; // 0x177c0

allocSize = swidthX2 * sheight; // 0x177c0 * 0xbbbb => 0x(1)135cca80

allocMem = HeapAlloc(ProcessHeap, 0, allocSize); // 0x135cca80 allocated

図 3: 整数オーバーフローの計算

POBitmapImageRep::initによって割り当てられた結果のヒープメモリは、イメージファイルからのデータを格納するために使用されます。これは、行ごとの 2 つのネストされたforループを使用して実行されます。 CCanonSRawLoadRaw::lossless_jpeg_load_rawの基礎となるコードは、 dcrawライブラリから C++ への関数の移植の結果です。

Table of contents

バリアント分析
パッチ
HEIF
パッチ
結論
付録

バリアント分析

この脆弱性の変種は、コードの他の部分でのHeapAllocの使用を相互参照することで簡単に見つけることができます。 CCanonSRawLoadRaw::GetBitmapImageには、ヒープオーバーフローにつながる同様のパターンの整数オーバーフローが含まれていました。 Microsoft は、これを別の脆弱性 CVE-2020-0997 として修正することを決定しました。

パッチ

Microsoft は、図 4 に示すように、乗算を 64 ビットに昇格させ、結果が 4 GiB を超えた場合に救済することで、両方の整数オーバーフローにパッチを適用しました。

allocSize64 = swidthx2 * (unsigned __int64)sheight;

if ( allocSize64 > 0xFFFFFFFF )

{

ATL::AtlThrowImpl(0x80070057);

}

allocSize = allocSize64;

ProcessHeap = GetProcessHeap();

allocMem = HeapAlloc(ProcessHeap, 0, allocSize);

図 4: CVE-2020-16968 パッチ

HEIF

High Efficiency Image File Format (HEIF) は、ISO Base Media File Format (ISOBMFF) に基づく、画像および画像シーケンス用の新しいより動的なコンテナー形式です。 Windows 10 は、 HEIF 画像拡張Windows ストアアプリを通じて HEIF をサポートします。 HEIF Image Extension は WIC にも対応しているため、ファザーを変更することなく、古いハーネスを使用して HEIF デコーダーにアクセスできます。

HEIF はコンテナ形式であるため、複数の圧縮形式をサポートしています。

HEIF (AVCI) の高度なビデオコーディング (AVC)
HEIF (HEIC) の高効率ビデオコーディング (HEVC)
HEIF (AVIF) の AOMedia ビデオ 1 (AV1)

Windows ストアの HEIF イメージ拡張機能は、AVC をサポートする基本的な HEIF コンテナーをサポートしています。 HEVCまたはAV1をデコードするには、追加の拡張機能をインストールする必要があります。 AV1 拡張機能のサポートはオープンソースのlibavifに基づいていますが、HEVC は Microsoft 独自のコードベースのようで、拡張機能をインストールするには 0.99 ドルの支払いが必要です (複雑な HEVC ライセンス条件のためと思われます)。すべての拡張機能は WIC に対応しており、HEIF は検出されたファイル形式に基づいて対応する拡張機能をロードするため、新しいハーネスは必要ありません。

HEIF をファジングするために、ファイルヘッダーに基づいて 3 つの個別のコーパスセットを収集し、脆弱性が見つかる可能性に基づいてファジングすることにしました。そのサポートは、OSSFuzz や他の研究者によって定期的にファジングされている libavif コードに基づいているため、私は AVIF のファジングに費やす金額を最小限に抑えました。 AVC コーデックの普及と、比較的新しいコーデックである新しい HEVC 拡張機能にほとんどの時間を費やしたことを考えると、AVC 拡張機能に費やされた時間はわずかでした。

これらのコーデックをファジングすると、想像以上に実り多いものになりました。何百ものクラッシュをトリアージした後、合計 35 件の脆弱性が Microsoft Response Center (MSRC) に報告され、21 件の CVE が発生しました。クラッシュのほとんどは HEVC 拡張機能によるもので、AVIF 拡張機能によるものはごくわずかでした。 HEIF 拡張機能で見つけた解放後のヒープ使用 (UAF) の興味深いケースを説明しましょう。前述の UAF の脆弱性 (CVE-2020-17101) によるクラッシュの例を図 5 に示します。

0:000> r

rax=0000029dec4dff60 rbx=0000029dec4dff60 rcx=0000029de5b20000

rdx=0000029de5b20000 rsi=0000029de9751e50 rdi=0000029dec4c5e80

rip=00007ffcce89ca2e rsp=000000e19c8ff2f0 rbp=000000e19c8ff479

r8=0000029dec4ddf30 r9=0000000000000001 r10=0000000000000000

r11=000000e19c8ff1f0 r12=0000000000000000 r13=00007ffcce9bd708

r14=0000029dec4c3fd0 r15=000000e19c8ff558

iopl=0 nv up ei pl nz na po nc

cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206

msheif_store!DllGetActivationFactory+0x79cbe:

00007ffc`ce89ca2e 488b9890000000 mov rbx,qword ptr [rax+90h] ds:0000029d`ec4dfff0=????????????????

0:000> !heap -p -a @rax

address 0000029dec4dff60 found in

_DPH_HEAP_ROOT @ 29de5b21000

in free-ed allocation ( DPH_HEAP_BLOCK: VirtAddr VirtSize)

29deb61f340: 29dec4df000 2000

00007ffd065c7db4 ntdll!RtlDebugFreeHeap+0x0000000000000038

00007ffd0657c018 ntdll!RtlpFreeHeap+0x0000000000097bc8

00007ffd064e95c4 ntdll!RtlpFreeHeapInternal+0x0000000000000464

00007ffd064e5d21 ntdll!RtlFreeHeap+0x0000000000000051

00007ffd03c2ea0b ucrtbase!_free_base+0x000000000000001b

00007ffcce89c931 msheif_store!DllGetActivationFactory+0x0000000000079bc1

00007ffcce989beb msheif_store!DllGetActivationFactory+0x0000000000166e7b

00007ffcce89ca55 msheif_store!DllGetActivationFactory+0x0000000000079ce5

00007ffcce8f0821 msheif_store!DllGetActivationFactory+0x00000000000cdab1 CHEIFImage::FinalParseAtom

00007ffcce8f0395 msheif_store!DllGetActivationFactory+0x00000000000cd625 CHEIFImage::CreateHEIFImage

00007ffcce8ac562 msheif_store!DllGetActivationFactory+0x00000000000897f2 CQTMovie::CreateMovieFromBuffer

00007ffcce8ee992 msheif_store!DllGetActivationFactory+0x00000000000cbc22

00007ffcce88afb2 msheif_store!DllGetActivationFactory+0x0000000000068242 CHEIFStreamReader::ParseStream

00007ffcce88a884 msheif_store!DllGetActivationFactory+0x0000000000067b14 CHEIFStreamReader::GetHEIFImage

00007ffcce82f2dc msheif_store!DllGetActivationFactory+0x000000000000c56c CHEIFParser::RuntimeClassInitialize

00007ffcce83963c msheif_store!DllGetActivationFactory+0x00000000000168cc

00007ffcce824f73 msheif_store!DllGetActivationFactory+0x0000000000002203

00007ffcce824c08 msheif_store!DllGetActivationFactory+0x0000000000001e98 MFCreateHEIFReaderFromStream

00007ffcce86c28b msheif_store!DllGetActivationFactory+0x000000000004951b CWICHeifDecoder::Initialize

00007ffcfc71334c windowscodecs!CCodecFactory::HrArbitrateDecoderList+0x0000000000000408

00007ffcfc715279 windowscodecs!CCodecFactory::HrCreateDecoderFromStreamInternalNew+0x000000000000030d

00007ffcfc7a918f windowscodecs!CCodecFactory::CreateDecoderFromFileHandle+0x000000000000008f

0:000> u @rip-7

msheif_store!sub_18007CA10+0x17:

00007ffc`ce89ca27 488b8798000000 mov rax,qword ptr [rdi+98h]

00007ffc`ce89ca2e 488b9890000000 mov rbx,qword ptr [rax+90h] ; crash

00007ffc`ce89ca35 4883a08800000000 and qword ptr [rax+88h],0

00007ffc`ce89ca3d 488b8f98000000 mov rcx,qword ptr [rdi+98h] ; same object

00007ffc`ce89ca44 4883c118 add rcx,18h

00007ffc`ce89ca48 488b01 mov rax,qword ptr [rcx] ; vftable

00007ffc`ce89ca4b 488b4010 mov rax,qword ptr [rax+10h] ; vfcall

00007ffc`ce89ca4f ff15b3d21000 call qword ptr [msheif_store!_guard_dispatch_icall_fptr (00007ffc`ce9a9d08)]

図 5: HEIF クラッシュ

CVE-2020-17101 の use-after-free は、ISOBMFF ヘッダー解析の非常に早い段階で発生します。コードパスは、サムネイルの作成によって呼び出すことができます。これにより、基本的にこれはゼロクリックのリモートコード実行 (RCE) になります。この RCE を有効にするのに役立つのは、Windows エクスプローラーでサムネイルが既定でオンになっていることです。

ISOBMFF は、ボックスまたはアトムを使用して、代表的なファイルに格納されているデータをカプセル化します。各ボックスには、長さフィールド (4 バイト)、ボックス名 ( fourCCバイトシーケンス)、およびオプションのメタデータとデータが含まれます。データには、他のボックスと対応するメタデータを含めることができます。

基本的なボックスの解析はバイト “ftyp” (図 6 のオフセット 4) から始まり、サポートされているブランドを探します。ここで、「mif1」はブランド、「heic」は画像コレクションのブランドです。通常の解析シナリオでは、「mif1」の後に「meta」ボックスが続き、「meta」ボックスは「hdlr」、「iloc」、「iinf」、「pitm」などの他のボックスをカプセル化します。

概念実証 (PoC) ファイル (図 6) を解析すると、”meta” ボックスの後に “xxxx” 汎用ボックスが続きます (“hdlr” と “pict” ではなく)。「pict」が欠落しているため、解析コードは次のボックス「pitm」と「iloc」を「型付きボックス」ではなく汎用ボックスと見なします。解析が「hdlr」ボックスに到達すると、「hdlr」ボックスと「pict」ボックスがタイプ付きボックスとして解析され、「meta」オブジェクトが更新されて見つかった「pict」ボックスがマークされます。ここで、解析は 2 番目の「pitm」ボックスに到達し、型指定されたボックスと見なされます。ポインターは「meta」オブジェクトで更新されます。次のボックス「zzzz」は汎用ボックスとして解析され、新しい「pitm」オブジェクトにアタッチされます。最初の解析はすべてCQTAtom::ScanChildren関数で行われます。

解析が最後に達し、 CHEIFImage::FinalParseAtom関数を呼び出すと、「iloc」、「iinf」、および「pitm」ボックスが見つかったかどうかがチェックされます。これらのボックスのいずれかが欠落している場合、オブジェクトのデストラクタが呼び出されてクリーンアップされ (オブジェクトは参照カウントされます)、関数CQTAtom::ScanChildrenを呼び出して解析が再開されます。デストラクタは、「pitm」に接続されている「zzzz」ボックスを解放しますが、「zzzz」オブジェクトへの格納されたポインタは「pitm」オブジェクトからヌルになりません。

解析が再開されると、「メタ」オブジェクトにはすでに「pict」があり、「xxxx」は汎用ボックスとして解析されますが、「pitm」と「iloc」(図 6 のオフセット 0x49 と 0x57) は入力ボックスとして解析されます。 .すでに「pitm」があるため、(完全な解析ではなく) その参照カウントがインクリメントされ、「iloc」が解析されます。この解析は失敗し、コードはエラーで救済されます。

解析が失敗したため、オブジェクトは再び破棄されます。デストラクタはリンクリストをループし、すべてのオブジェクトのデストラクタを呼び出します。「pitm」オブジェクトには、解放された「zzzz」オブジェクトへのポインタ参照がまだあるため、コードは、解放されたオブジェクトの仮想関数テーブルにアクセスし、デストラクタを仮想関数として呼び出すことによって、「zzzz」オブジェクトをもう一度解放しようとします。ファジングされたプロセスのページヒープを有効にしているため、これによりクラッシュが発生します。

パッチ

Microsoft は、メモリを解放した後に保存されたポインター参照を無効にすることにより、この脆弱性にパッチを適用しました。

結論

このブログシリーズのパート 3 では、Windows の組み込みイメージパーサーの複数の脆弱性を紹介し、Windows でサポートされている新しいイメージフォーマットを紹介します。報告されたすべての脆弱性のリストは、次の付録に記載されており、 Mandiant Vulnerability Disclosuresで参照されています。

付録

CVE ID	提出日	確定日	脆弱性の種類
CVE-2020-0997	2020 年 7 月 1 日	2020 年 9 月 8 日	整数オーバーフロー
CVE-2020-16968	2020 年 7 月 1 日	2020 年 10 月 13 日	整数オーバーフロー
CVE-2020-17022	2020 年 7 月 3 日	2020 年 10 月 13 日	ヒープ/スタックオーバーフロー
CVE-2021-24110	2020 年 7 月 7 日	2021 年 3 月 9 日	ヒープオーバーフロー
CVE-2021-1643	2020 年 7 月 8 日	2021 年 1 月 12 日	ヒープオーバーフロー
CVE-2020-17101	2020年7月10日	2020 年 11 月 10 日	無料後に使用
CVE-2020-17107	2020年7月13日	2020 年 11 月 10 日	ヒープオーバーフロー
CVE-2020-17106	2020年7月13日	2020 年 11 月 10 日	ヒープオーバーフロー
CVE-2020-17108	2020年7月21日	2020 年 11 月 10 日	ヒープオーバーフロー
CVE-2020-17109	2020 年 7 月 30 日	2020 年 11 月 10 日	ヒープオーバーフロー
CVE-2020-17105	2020年8月13日	2020 年 11 月 10 日	ヒープオーバーフロー
CVE-2020-17110	2020年8月31日	2020 年 11 月 10 日	ヒープオーバーフロー
CVE-2021-27048	2020 年 10 月 14 日	2021 年 3 月 9 日	ヒープオーバーフロー
CVE-2021-27047	2020 年 10 月 14 日	2021 年 3 月 9 日	ヒープオーバーフロー
CVE-2021-27049	2020 年 10 月 14 日	2021 年 3 月 9 日	ヒープオーバーフロー
CVE-2021-27051	2020 年 10 月 14 日	2021 年 3 月 9 日	ヒープオーバーフロー
CVE-2021-26902	2020 年 10 月 23 日	2021 年 3 月 9 日	ヒープオーバーフロー
CVE-2021-27061	2020 年 10 月 23 日	2021 年 3 月 9 日	ヒープオーバーフロー
CVE-2021-24089	2020 年 10 月 23 日	2021 年 3 月 9 日	ヒープ/スタックオーバーフロー
CVE-2021-33775	2021 年 3 月 24 日	2021 年 7 月 13 日	ヒープオーバーフロー
CVE-2021-33777	2021 年 3 月 24 日	2021 年 7 月 13 日	初期化されていないメモリ
CVE-2021-33778	2021 年 3 月 24 日	2021 年 7 月 13 日	ヒープオーバーフロー
CVE-2021-38661	2021 年 4 月 27 日	2021 年 9 月 14 日	ヒープオーバーフロー

参照: https://www.mandiant.com/resources/blog/fuzzing-image-parsing-three

バリアント分析

パッチ

HEIF

パッチ

結論

付録

Comments