Windows の画像解析の脆弱性 に関する議論を続けると、比較的人気の低い脆弱性クラスである初期化されていないメモリに注目します。この投稿では、Windows に組み込まれているイメージ パーサー、特に初期化されていないメモリの使用に関連する脆弱性について説明します。
脆弱性: 初期化されていないメモリ C や C++ などのアンマネージ言語では、変数は既定では初期化されません。初期化されていない変数を使用すると、未定義の動作が発生し、クラッシュする可能性があります。初期化されていないメモリには、大まかに次の 2 つのバリアントがあります。
初期化されていないメモリの直接使用: 初期化されていないポインタまたはインデックスが読み取りまたは書き込みで使用されています。これにより、クラッシュが発生する可能性があります。
初期化されていないメモリの使用による情報漏えい (情報漏えい): 初期化されていないメモリの内容は、セキュリティ境界を越えてアクセスできます。例: 初期化されていないカーネル バッファがユーザー モードからアクセスできるため、情報漏えいにつながります。
この投稿では、攻撃者が JavaScript を使用してデコードされた画像を読み取ることができる Web ブラウザーなどの状況で、情報漏えいにつながる Windows 画像パーサーの 2 番目の亜種を詳しく見ていきます。
初期化されていないメモリの脆弱性の検出 ヒープ オーバーフローや解放後の使用などのメモリ破損の脆弱性と比較して、初期化されていないメモリの脆弱性自体は、範囲外または範囲外のメモリにアクセスしません。これにより、これらの脆弱性の検出は、メモリ破損の脆弱性よりも若干複雑になります。初期化されていないメモリを直接使用するとクラッシュが発生する可能性があり、それを検出することはできますが、通常、情報漏えいによってクラッシュが発生することはありません。それを検出するには、MemorySanitizer などのコンパイラ インストルメンテーションまたは Valgrind などのバイナリ インストルメンテーション/再コンパイル ツールが必要です。
回り道: Linux で初期化されていないメモリを検出する 少し寄り道して、Linux での初期化されていないメモリの検出を見て、Windows の組み込み機能と比較してみましょう。コンパイラは一部の初期化されていない変数について警告しますが、初期化されていないメモリ使用量の複雑なケースのほとんどは、コンパイル時に検出されません。このために、ランタイム検出メカニズムを使用できます。 MemorySanitizer は、初期化されていないメモリ読み取りを検出する、GCC と Clang の両方のコンパイラ インストルメンテーションです。それがどのように機能するかのサンプルを図 1 に示します。
$猫サンプル.cc
int main()
$ clang++ -fsanitize=memory -fno-omit-frame-pointer -g sample.cc
$ ./a.out
概要: MemorySanitizer: 初期化されていない値の使用 (/home/dan/uni/a.out+0x496db8)
図 1: 初期化されていないメモリの MemorySanitizer 検出
同様に、Valgrind を使用して、実行時に初期化されていないメモリを検出することもできます。
Windows で初期化されていないメモリを検出する Linux と比較して、Windows には初期化されていないメモリ使用量を検出する組み込みメカニズムがありません。 Visual Studio と Clang-cl は最近AddressSanitizer サポート を導入しましたが、MemorySanitizer とその他のサニタイザーは、この記事の執筆時点では実装されていません。
PageHeap など、メモリ破損の脆弱性を検出するための Windows の便利なツールの一部は、初期化されていないメモリの検出には役立ちません。反対に、PageHeap はメモリ割り当てをパターンで満たすため、基本的に初期化されます。
Dr.Memory など、バイナリ インストルメンテーションを使用してヒープ オーバーフロー、初期化されていないメモリ使用量、解放後の使用などのメモリの安全性の問題を検出するサードパーティ ツールはほとんどありません。
画像デコードにおける初期化されていないメモリの検出 Windows で初期化されていないメモリを検出するには、通常、特にソース コードにアクセスできない場合、バイナリ インストルメンテーションが必要です。初期化されていないメモリ使用量を検出するために使用できる指標の 1 つは、特に画像のデコードの場合、画像がデコードされた後の結果のピクセルです。
画像がデコードされると、生のピクセルのセットが生成されます。画像のデコードで初期化されていないメモリが使用されると、一部またはすべてのピクセルがランダムになる可能性があります。簡単に言えば、初期化されていないメモリが使用されている場合、画像を複数回デコードすると、毎回異なる出力になる可能性があります。この出力の違いを使用して、初期化されていないメモリを検出し、Windows イメージ デコーダーをターゲットとするファジング ハーネスの作成を支援できます。ファジング ハーネスの例を図 2 に示します。
#ROUNDS 20 の定義
unsigned char* DecodeImage(char *imagePath)
// GDI または WIC を使用して画像をデコードし、結果のピクセルを取得します
ピクセルを返します。
void Fuzz(char *imagePath)
if(refPixels != NULL)
図 2: デフ ハーネス
このファジング ハーネスの背後にあるアイデアは、まったく新しいものではありません。以前は、 lcamtuf が同様のアイデアを使用して、オープンソースの画像パーサーで初期化されていないメモリを検出し、Web ページを使用してピクセルの違いを表示していました。
ファジング 差分ハーネスの準備ができたら、サポートされている画像形式を探して、コーパスを収集することができます。コーパス用の画像ファイルを収集することは、インターネット上でほぼ無制限に利用できることを考えるとかなり簡単ですが、同時に、独自のコード カバレッジを持つ何百万ものファイルの中から適切なコーパスを見つけることは困難です。 Windows イメージ解析のコード カバレッジ情報は、WindowsCodecs.dll から追跡されます。
通常の Windows ファジングとは異なり、PageHeap はパターンを使用してヒープ割り当てを「初期化」するため、今回は PageHeap を有効にしないことに注意してください。
結果 調査中に、Windows の組み込みイメージ パーサーをファジングしているときに、メモリ使用量が初期化されていないケースが 3 つ見つかりました。そのうちの 2 つについては、次のセクションで詳しく説明します。初期化されていないメモリ使用量の根本原因の分析は簡単ではありません。バック トレースするクラッシュの場所がなく、結果のピクセル バッファーをバック トレースに使用して根本原因を見つけるか、巧妙なトリックを使用して偏差を見つける必要があります。
CVE-2020-0853 この脆弱性の根本原因に入る前に、概念実証 (PoC) ファイルのレンダリングを見てみましょう。このために、PoC 画像を複数回読み込み、ピクセルを参照ピクセルと比較する lcamtuf の HTML を使用します。
図 3: CVE-2020-0853 結果の画像 (図 3) からわかるように、出力はデコードごとに大幅に変化し、この PoC が初期化されていないメモリを大量にリークしていると推測できます。
これらの脆弱性の根本原因を特定するために、Time Travel Debugging (TTD) を広範囲に使用しました。実行をさかのぼってメモリ アドレスを追跡するのは面倒な作業ですが、TTD を使用すると、アドレスと値を一定に保ち、無制限に順方向および逆方向の実行を提供することで、わずかに負担が軽減されます。
トレースのデバッグにかなりの時間を費やした後、 windowscodecs!CFormatConverter::Initialize に初期化されていないメモリのソースが見つかりました。ソースが見つかったとしても、このメモリがまったく上書きされずにピクセルの計算で終了する理由は最初は明らかではありませんでした。この謎を解決するために、PoC 実行トレースを通常の TIFF ファイルのデコードと比較することで、追加のデバッグが行われました。次のセクションでは、ピクセル計算への初期化されていない値の割り当て、コピー、および脆弱性の実際の根本原因を示します。
初期化されていないメモリの割り当てと使用 windowscodecs!CFormatConverter::Initialize は、0x40 バイトのメモリを割り当てます (図 4 参照)。
0:000>r
//割り当て後に初期化されていないメモリ :
図 4: メモリの割り当て
メモリは決して書き込まれず、初期化されていない値はwindowscodecs!CLibTiffDecoderBase::HrProcessCopy で反転され、windowscodecs! GammaConvert_16bppGrayInt_128bppRGBA でさらに処理され、後でスケーリング関数と呼ばれます。
HrProcessCopy の前に初期化されていないメモリへの読み取りまたは書き込みがないため、HrProcessCopy から実行をトレースし、実行トレースを通常の tiff デコード トレースと比較しました。通常の TIFF ファイルと比較して、 windowscodecs!CLibTiffDecoderBase::UnpackLine が PoC ファイルで動作する方法に違いが見つかりました。UnpackLine の関数パラメーターの 1 つは、初期化されていないバッファーへのポインターでした。
UnpackLine 関数には、TIFF イメージのサンプルあたりのビット数 (BPS) を操作する一連の switch-case ステートメントがあります。この PoC TIFF ファイルでは、BPS 値は 0x09 ( UnpackLine ではサポートされていません) であり、制御フローはバッファーに書き込むコード パスに到達しません。これが初期化されていないメモリの根本的な原因であり、パイプラインのさらに下で処理され、最終的にピクセル データとして表示されます。
パッチ 私の分析を Microsoft に提示した後、Microsoft は、サポートされていない BPS 値を含むファイルを無効にすることで、脆弱性にパッチを当てることにしました。これにより、すべてのデコードが回避され、読み込みの非常に早い段階でファイルが拒否されます。
CVE-2020-1397 図 5: CVE-2020-1397 のレンダリング 前の脆弱性とは異なり、図 5 に示すように、この脆弱性では出力の違いはかなり限定的です。特定のタイプの初期化されていないメモリ使用量を把握するために使用できる、より単純な根本原因分析手法の 1 つは、実行トレースを比較することです。 2 つの異なる出力を生成する実行。この特定の手法は、初期化されていない変数によってプログラム内の制御フローが変更され、出力に違いが生じる場合に役立ちます。このために、バイナリ インストルメンテーション スクリプトが作成されました。このスクリプトは、実行されたすべての命令をレジスタと共に記録し、メモリ値にアクセスしました。
命令ポインター (RIP) の値を比較して 2 つの異なる実行トレースを比較したところ、初期化されていない値の使用により、 windowscodecs!CCCITT::Expand2DLine で制御フローが変更されていることがわかりました。 TTD トレースを使用して初期化されていない値を逆トレースすることは、根本原因を見つけるのに非常に役立ちました。次のセクションでは、制御フローの変更とピクセル出力の逸脱につながる、初期化されていない値の割り当て、設定、および使用について説明します。
割り当て windowscodecs!TIFFReadBufferSetup は、図 6 に示すように、0x400 バイトのメモリを割り当てます。
windowscodecs!TIFFReadBufferSetup:
0:000>k
割り当て後:
//割り当て後に初期化されていないメモリ
図 6: メモリの割り当て
バッファの部分的な移入 TIFFReadRawStrip1 によって、入力ファイルからこの割り当てられたバッファに 0x10 バイトがコピーされます。図 7 に示すように、バッファーの残りの部分は、ランダムな値で初期化されていないままになります。
if ( !TIFFReadBufferSetup(v2, a2, stripCount) ) {
0:000>r
0:000> デシベル 00000297`44382140ファイルから 0x10 バイト
図 7: メモリの部分的な実装
初期化されていないメモリの使用
0:000>rアクセス中の初期化されていないメモリ
0:000> デシベル 00000297`44382140ファイルから 0x10 バイト
0:000>k
図 8: 初期化されていない値の読み取り
初期化されていない値 (図 8) に応じて、Expand2DLine で異なるコード パスが使用され、図 9 に示すように、出力ピクセルが変更されます。
{
図 9: if 条件での初期化されていないメモリの使用
パッチ Microsoft は、割り当てられたメモリをゼロで初期化するmalloc の代わりにcalloc を使用して、この脆弱性にパッチを適用することを決定しました。
結論 このブログ シリーズのパート 2 では、Windows の組み込みイメージ パーサーに複数の脆弱性が存在します。次の投稿では、RAW、HEIF など、Windows でサポートされている新しい画像形式について説明します。
Comments