例外の中の例外: 特殊なケースを処理するシステム例外を使用して、驚異的な脆弱性を実現しますexploitation_html/css_WEB-ITnose

原著者: tombkeeper

メモリの読み取り、書き込み、実行属性は、システム セキュリティにとって最も重要なメカニズムの 1 つです。通常、メモリ内のデータを書き換える場合は、まずメモリが書き込み可能属性であることを確認する必要があります。メモリ内でコードを実行する場合は、まずメモリが実行可能属性であることを確認する必要があります。例外がスローされます。ただし、Windows システムの例外処理プロセスにはいくつかの小さな例外があり、これらの例外を利用すると、書き込み可能でないことがわかっている場合は書き込み、実行可能でないことがわかっている場合は実行できます。

0×01 読み取り専用メモリを直接書き換えます

CanSecWest 2014 での講演「ROP は 99% のためのものです」で、私は興味深い IE ブラウザの脆弱性悪用技術を紹介しました: 特定のフラグの変更によるJavaScript オブジェクトではセーフ モードがオフになり、IE が WScript.Shell などの危険なオブジェクトを読み込み、DEP を考慮せずに任意のコードを実行できるようになります。

ただし、セーフモード フラグを変更することだけが、IE に危険なオブジェクトの読み込みを許可する唯一の方法ではありません。

IE ブラウザの一部のインターフェイスは実際には HTML で実装されており、通常は ieframe.dll のリソースに保存されます。たとえば、印刷プレビューは res://ieframe.dll/preview .dlg です。コレクション フォルダーは res://ieframe.dll/orgfav.dlg、ページ属性は res://ieframe.dll/docppg.ppg です。

IE ブラウザは、これらの HTML に対して独立したレンダリング インスタンスと独立した JavaScript エンジン インスタンスを作成します。これらの HTML 用に作成された JavaScript エンジン インスタンスでは、セーフモード自体がオフになっています。

つまり、JavaScript コードを ieframe.dll のリソースに挿入し、IE の対応する関数をトリガーするだけです。挿入されたコードは、セーフモードがオフになっている JavaScript インスタンスの下で IE 独自の関数コードとみなされます。埋め込む。

ただし、PE のリソース セクションは読み取り専用であり、任意のアドレスに書き込みできる脆弱性を利用して ieframe.dll のリソースを直接書き換えようとすると、書き込みアクセス違反がトリガーされます。 >

上記の例外処理チェーンでは、mshtml.dll の例外処理関数が最終的に kernel32!RaiseFailFastException() を呼び出します。 g_fFailFastHandlerDisabled フラグが false の場合、現在のプロセスは終了します:

ただし、g_fFailFastHandlerDisabled フラグが true の場合、例外処理チェーンは kernel32!UnhandledExceptionFilter() まで実行されます。最後に kernel32! CheckForReadOnlyResourceFilter():

BasepAllowResourceConversion も true の場合、CheckForReadOnlyResource() 関数は書き込みしようとしているメモリ ページの属性を書き込み可能として設定して戻ります。普通に。

つまり、最初に 2 つのフラグ g_fFailFastHandlerDisabled と BasepAllowResourceConversion を true に書き換えると、その読み取り専用属性を気にせずに ieframe.dll のリソースを直接変更でき、オペレーティング システムがそれを処理します。すべて。

小さな問題もあります。 CheckForReadOnlyResource() でメモリ属性を変更する操作が前述のようにトリガーされた場合、メモリ属性の RegionSize もメモリ ページのサイズ (通常は 0x1000) になります。 IE は、ieframe.dll 内の HTML リソースを使用してレンダリング インスタンスを作成する前に、mshtml!GetResource() 関数によって、リソースが配置されているメモリの RegionSize 属性がチェックされます。属性がリソースのサイズより小さい場合は、その属性がチェックされます。返品失敗。ただし、書き換えられるリソースが最初から最後まで書き換えられる限り、RegionSize はそれに応じて増加するため、このチェックはバイパスされます。

このように、Windows の書き込みアクセス例外を使用して PE ファイルのリソース セクションにゴーサインを与えることで、非常に素晴らしい脆弱性悪用コードを書くことができます。

0×02 非実行可能メモリの直接実行

VARA 2009 での講演「脆弱性マイニングにおける時間の次元」で、リリース後の脆弱性の比較的まれなモジュール アドレスの再利用について紹介しました。たとえば、プログラム内で、スレッド A がモジュール X の関数を呼び出し、モジュール X がモジュール Y の関数を呼び出します。何らかの理由で、モジュール Y の関数が戻るまでに時間がかかります。戻る前に、スレッド B がモジュール X を解放できる場合、モジュール Y の関数が戻るとき、戻りアドレスは無効になります。当時、OperaブラウザではFlashモジュールを利用してこの脆弱性を引き起こす可能性があることが判明し、国内のダウンロードツールでも同様の問題が発生していた。

他にも多くの種類の脆弱性があり、最終的なパフォーマンスは上記の問題と同じになります。固定ポインタを実行することはできますが、ポインタの値を制御することはできません。 DEP のない環境では、コードが実行されるアドレスにスプレーされる限り、これらの脆弱性を悪用するのは難しくありません。 DEP 環境では、通常、これらの脆弱性を悪用することは不可能であると考えられています。

しかし、次のデータが実行が予想されるアドレスにスプレーされた場合:

ヒープ スプレーにもかかわらず、DEP 環境であっても、メモリ領域は間違いなく実行可能ではありませんが、システムが依然としてこれらの命令を実行し、ecx によって設定されたアドレスにジャンプしているように見えることに驚かれるでしょう。 ecx が適切な値に設定されている限り、任意のアドレスにジャンプして ROP チェーンを実行できます。

これは、Windows システムが一部の古いバージョンのプログラムと互換性を保つために ATL サンク エミュレーションと呼ばれるメカニズムを実装しているためです。システム カーネルは、実行アクセス例外を処理するときに、例外アドレスのコードが ATL サンク特性に準拠しているかどうかをチェックします。 ATL サンク特性を満たすコードの場合、カーネルは KiEmulateAtlThunk() 関数を使用してコードをシミュレートし、実行します。

ATL サンク エミュレーション メカニズムは、ジャンプ先のアドレスが PE ファイル内にあるかどうかをチェックし、CFG をサポートするシステムでは、ジャンプ先のアドレスが CFG チェックに合格できるかどうかも確認します。同時に、Vista 以降の Windows のデフォルト DEP ポリシーでは、ATL サンク エミュレーション メカニズムは、IMAGE_DLLCHARACTERISTICS_NX_COMPAT を設定していないプログラムに対してのみ有効です。プログラムのコンパイル時に /NXCOMPAT パラメーターが指定されている場合、ATL サンク エミュレーションとの互換性はなくなります。ただし、多くのサードパーティ アプリケーションや 32 ビット iexplore.exe など、ATL サンク エミュレーションをサポートするプログラムはまだ多数あります。したがって、ハッキング チームが漏洩した電子メールの CVE-2015-2425 と同様に、ある種のヒープ スプレーを使用してメモリを正常に占有することができれば、この手法を使用して脆弱性を悪用することもできます。

このように、システム例外処理プロセスで ATL サンク エミュレーションの機能を使用して、実行不可能なメモリを直接実行することで、通常悪用不可能と考えられている一部の脆弱性を復活させることができます。

(この記事の内容の大部分は 2014 年 10 月に完成しました。関連するモジュール アドレス、シンボル情報などは、Internet Explorer 11 を使用した Windows Technical Preview 6.4.9841 x64 に基づいています。)

参考:

[1] ROP は 99% 用、CanSecWest 2014

[2] ブラウザのメモリ保護のバイパス

[3] (CVE- 2015-2425) ハッキング チームからの「ギフト」継続、IE ゼロデイをミックスに追加

[4] 「脆弱性マイニングの時間次元」、VARA 2009

*著者: tombkeeper、この記事は Tencent Xuanwu Lab ブログで最初に公開されたものです。転載する場合は、FreeBuf Hackers and Geeks (FreeBuf.COM) からのものであることを明記してください