CVE-2019-9810 Windows上のFirefox向けエクスプロイト

CVE-2019-9810は、Pwn2Own 2019にてRichard Zhu氏とAmat Cama氏によって発見・悪用された脆弱性です。MozillaのJavaScriptエンジンSpidermonkeyに影響を与え、レンダラーの侵害に利用されました。

この問題は約2ヶ月前にmfsa2019-09で修正されました。

問題の概要

一言で言えば、このバグにより境界チェックが冗長と判断されて最適化で除去され、コードがメモリ範囲外にアクセスできるようになります。問題自体はIonのパイプラインのエイリアス解析パスにあります。以下の画像は、GVN最適化パス（境界チェックが最適化で除去される）におけるバグの結果を示しており、これが探しているものであれば良い要約となります。

しかし、さらに詳しく知りたい方は、A journey into IonMonkey: root-causing CVE-2019-9810をご覧になることをお勧めします。

構成

リポジトリにはエクスプロイトコードと、以前blazefoxエクスプロイト用に開発した多数のツールが含まれています。これらをブラッシュアップし、BigIntで動作するようにしました。その結果、このエクスプロイトはFirefoxでBigIntのサポートが有効になっていることを前提としています。これはabout:configでjavascript.options.bigintを切り替えることで有効にできます。

bigint

このエクスプロイトはWindows RS5 64-bitでテストされており、カスタムビルドのFirefoxを対象としているため、他の環境で動作させるには多少の作業が必要でも驚かないでください:)。ただし、コンパイルせずにエクスプロイトを実行したい場合のために、release/firefox-68.0a1.en-US.win64.7zにアップロードしたパッケージ版ブラウザを用意しました。これにはjs.exeシェルと、js.exe、firefox.exe、xul.dllのプライベートシンボル情報も含まれています。

エクスプロイトのプロセスは、前述の以前のkaizen.jsエクスプロイトと非常によく似ています。ペイロードを実装するreflective dllのReflectiveLoaderに実行をディスパッチします。

ペイロードがjs.exeから呼び出されたことを検出すると、単にstdoutにPWNを大量に出力し、電卓を起動して終了します。
ブラウザから実行される場合、最初に自身を他のFirefox.exeプロセスに注入します。そのために、Javascriptエクスプロイトはreflective dllのコピーへのポインタを渡し、reflective dllがそれを他のプロセスにマッピングします。これが完了すると、reflective loader上にリモートスレッドを作成し、休止します。その理由は、エクスプロイトが現在の状態では非常に汚く、プロセスの継続を実装していないためです。とはいえ、この時点ではそれほど大した作業ではないと思います。いつかやるかもしれません:-)。
ペイロードが他のFirefox.exeから実行されると、xul!nsJSUtils::ExecutionContext::Compile関数をインラインフックします。この関数はスクリプトをJavaScriptエンジンで評価する必要があるときに実行されます。そのため、私の目的にとって十分な候補に思えました。フックされたバージョンは、選択した任意のJavaScriptペイロードを単に先頭に追加します。
フックが設置されると、単に戻ります。この時点で、他のオリジンには任意のJavaScriptが注入されています。私が使用するペイロードは、それらのオリジンの背景画像をDiary of a reverse-engineerのテーマ画像に変更し、すべてのリンクをブログにリダイレクトするというものです:)。

実際には、上記では説明されていない多くの微妙な詳細があります。興味があれば、ぜひ真実を探しに行き、ソースを読んでみてください:)。

ペイロードのビルド

ペイロードをビルドするには、VS 2017 x64プロンプトからnmakeを実行するだけです。

CVE-2019-9810\payload>nmake

Microsoft (R) Program Maintenance Utility Version 14.16.27027.1
Copyright (C) Microsoft Corporation.  All rights reserved.

        ml64 /c src\trampoline.asm
Microsoft (R) Macro Assembler (x64) Version 14.16.27027.1
Copyright (C) Microsoft Corporation.  All rights reserved.

 Assembling: src\trampoline.asm
        if not exist .\bin mkdir bin
        type injected-script.js > src\injected-script.h
        cl /O1 /nologo /W3 /D_AMD64_ /DWIN_X64 /DREFLECTIVEDLLINJECTION_CUSTOM_DLLMAIN /Febin\payload.dll src\ReflectiveLoader.c src\ReflectiveDll.cc trampoline.obj /link /DLL /nologo /debug:full /PDBALTPATH:%_PDB%
ReflectiveLoader.c
Generating Code...
Compiling...
ReflectiveDll.cc
Generating Code...
   Creating library bin\payload.lib and object bin\payload.exp
        python jsify_payload.py bin\payload.dll
        move payload.js ..
        1 file(s) moved.
        del *.obj
        del src\injected-script.h
        if exist .\bin del bin\*.exp bin\*.ilk bin\*.lib

これにより、payload\binディレクトリ内にpayload.dll/payload.pdbファイルが作成されます。また、payload.jsというJavaScriptファイルも作成され、ローダーへのオフセットとともにDLLがUint8Arrayに埋め込まれます。

Firefoxのビルド

このエクスプロイトは、以下のリビジョンIDに同期されたローカルWindowsビルドに対して作成しました: 2abb636ad481768b7c88619080cf224b2c266b2d（自分でビルドしたくない場合は、ビルドをこちらにアップロードしてあります: release/firefox-68.0a1.en-US.win64.7z）

$ hg --debug id -i
2abb636ad481768b7c88619080cf224b2c266b2d

そして、以下のmozconfigファイルを使用しました:

. "$topsrcdir/browser/config/mozconfigs/win64/common-win64"

ac_add_options --disable-crashreporter
ac_add_options --enable-debug-symbols

. "$topsrcdir/build/mozconfig.clang-cl"
. "$topsrcdir/build/mozconfig.lld-link"

# Use the clang version in .mozbuild
CLANG_LIB_DIR="$(cd ~/.mozbuild/clang/lib/clang/*/lib/windows && pwd)"
export LIB=$LIB:$CLANG_LIB_DIR

ac_add_options --enable-js-shell
ac_add_options --enable-jitspew
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-ff64

議論

私の目的には十分でしたが、xul!nsJSUtils::ExecutionContext::Compileが任意のスクリプトを挿入するための完璧な関数かどうかは疑問です。xulのフロントエンドの動作を少し理解するためにより多くの時間を費やせば、より良いフックポイントを思いつくことができると確信しています。

エクスプロイト作成後に発見したさらにいくつかの方向性が、このbugzillaエントリで議論されています: 982974（JavaScriptインタプリタのシステムプリンシパルとsecurity.turn_off_all_security_so_that_viruses_can_take_over_this_computer）。これが今日のFirefoxにどれだけ関連しているのかを見るのは興味深いでしょう。

おそらく誰かがこの主題をすでに研究していて、私は完全に見逃しているかもしれません。いずれにせよ、フィードバックがあればお気軽にご連絡ください！

もう一つ興味深いのは、ブラウザ内で永続化メカニズムを持つ方法があるかどうかを探ることです。この分野は全く研究していませんが、かなりクールでしょう:)。

CVE-2019-9810

人気

CVE-2019-9810 Windows上のFirefox向けエクスプロイト

問題の概要

構成

ペイロードのビルド

Firefoxのビルド

議論