Windows でのアドレス空間レイアウトのランダム化に関する 6 つの事実

アドレス空間レイアウトのランダム化 (ASLR) を克服することは、事実上すべての最新のメモリ破損の脆弱性の前提条件です。 ASLR を破ることは活発に研究されている分野であり、信じられないほど複雑になる可能性があります。このブログ投稿では、Windows の実装に焦点を当てて、ASLR に関するいくつかの基本的な事実を紹介します。 ASLR がセキュリティ体制を改善するために何を達成するかをカバーすることに加えて、ソフトウェアのセキュリティを改善する方法について防御者にアドバイスを提供し、ASLR がどのように機能するかについてのより多くの洞察とその制限を調査するためのアイデアを研究者に提供することを目的としています。

メモリ破損の脆弱性は、意図したメモリ領域外または意図したメモリの範囲外に攻撃者が制御するデータをプログラムが誤って書き込むときに発生します。これにより、プログラムがクラッシュしたり、さらに悪いことに、攻撃者がシステムを完全に制御できるようになる可能性があります。メモリ破損の脆弱性は、Apple、Google、Microsoft などの大企業による撲滅の取り組みにもかかわらず、何十年にもわたってソフトウェアを悩ませてきました。

これらのバグは見つけるのが難しく、たった 1 つでもシステムが侵害される可能性があるため、セキュリティの専門家は、ソフトウェアの悪用を阻止し、メモリ破損のバグが悪用された場合の損害を制限するフェイルセーフ メカニズムを設計しました。 「銀の弾丸」は、エクスプロイトを非常にトリッキーで信頼性の低いものにして、バグのあるコードをそのままにしておくことができるメカニズムであり、開発者はメモリセーフな言語でコードを修正または書き直すために必要な年数を与えられます。残念ながら完璧なものはありませんが、アドレス空間レイアウトのランダム化 (ASLR) は利用可能な最適な軽減策の 1 つです。

ASLR は、プログラムやライブラリが実行時にメモリ内のどこにあるのかについて開発者が行う可能性のある仮定を破ることによって機能します。一般的な例は、リターン指向プログラミング (ROP) で使用されるガジェットの場所です。ROP は、データ実行防止 (DEP) の防御を無効にするためによく使用されます。 ASLR は、脆弱なプロセスのアドレス空間 (メイン プログラム、その動的ライブラリ、スタックとヒープ、メモリ マップ ファイルなど) を混同するため、エクスプロイト ペイロードは被害者プロセスのアドレス空間に合わせて独自に調整する必要があります。時に配置されます。ハードコーディングされたメモリ アドレスを使用して、メモリ破損のエクスプロイトを検出可能なすべてのマシンに盲目的に送信することによって増殖するワームを作成すると、必ず失敗します。ターゲット プロセスで ASLR が有効になっている限り、エクスプロイトのメモリ オフセットは、ASLR が選択したものとは異なります。これにより、脆弱なプログラムを悪用するのではなく、クラッシュさせます。

事実 1: ASLR は Windows Vista で導入されました。 Windows の Pre-Vista バージョンには ASLR がありませんでした。さらに悪いことに、すべてのプロセスとマシンで一貫したアドレス空間を維持するために多大な努力を払っていました。

Windows Vista と Windows Server 2008 は、互換性のある実行可能ファイルとライブラリの ASLR をサポートする最初のリリースです。以前のバージョンでは、単にアドレス空間をランダム化せず、代わりに、その時点で都合のよい場所に DLL をロードしただけだと考える人もいるかもしれません。残念ながら、これらの古いバージョンの Windows は、私たちが「アドレス空間レイアウトの一貫性」と呼ぶものを達成するのに苦労しました。表 1 は、Windows XP Service Pack 3 の一部のコア DLL の「優先ベース アドレス」を示しています。

表 1: Windows DLL には、ASLR が配置されていない場合に可能な限り使用される優先ベース アドレスが含まれています

プロセスを作成するとき、Vista より前の Windows は、可能であれば、プログラムに必要な各 DLL を優先ベース アドレスにロードします。たとえば、攻撃者が ntdll の 0x7c90beef で便利な ROP ガジェットを見つけた場合、攻撃者は、将来のサービス パックまたはセキュリティ パッチで DLL の再編成が必要になるまで、そのアドレスで常に使用できると想定できます。これは、Vista より前の Windows に対する攻撃が、一般的な DLL からの ROP ガジェットを連鎖させて、これらのリリースの唯一のメモリ破損防御である DEP を無効にできることを意味します。

Windows が優先ベース アドレスをサポートする必要があったのはなぜですか?その答えは、パフォーマンスと、Windows DLL の設計と ELF 共有ライブラリなどの他の設計とのトレードオフにあります。 Windows DLL は、位置に依存しません。特に 32 ビット マシンでは、Windows DLL コードがグローバル変数を参照する必要がある場合、その変数のランタイム アドレスがマシン コードにハードコーディングされます。 DLL が予想とは異なるアドレスにロードされた場合、そのようなハードコーディングされた参照を修正するために再配置が実行されます。代わりに DLL が優先ベース アドレスとして読み込まれる場合、再配置は必要なく、DLL のコードをファイル システムからメモリに直接マップできます。

DLL ファイルをメモリに直接マッピングすると、必要になるまで DLL のページを物理メモリに読み込む必要がなくなるため、パフォーマンスがわずかに向上します。優先ベース アドレスを使用するより適切な理由は、DLL のコピーが 1 つだけメモリに存在する必要があることを確認するためです。それらがないと、共通の DLL を共有する 3 つのプログラムが実行され、それぞれがその DLL を異なるアドレスでロードする場合、メモリには 3 つの DLL コピーが存在し、それぞれが異なるベースに再配置されます。それは、そもそも共有ライブラリを使用することの主な利点を打ち消すことになります。セキュリティ上の利点は別として、ASLR は、ロードされた DLL のアドレス空間が重複しないことを保証し、DLL の1 つのコピーのみをメモリにロードするという同じことを、より洗練された方法で実現します。 ASLR は、静的に割り当てられた優先ロード アドレスよりもアドレス空間間のオーバーラップを回避するのに優れているため、手動で優先ベース アドレスを割り当てても、ASLR 対応 OS では最適化されず、開発ライフサイクルでは不要になりました。

要点 1.1: Windows XP および Windows Server 2003 以前は ASLR をサポートしていません。

明らかに、これらのバージョンは何年もの間サポートされておらず、本番環境で使用されなくなって久しいはずです。より重要な観察結果は、Windows のレガシ バージョンと最新バージョンの両方をサポートするソフトウェア開発者に関連しています。まったく同じプログラムでも、実行している OS のバージョンによって安全性が高くなったり低くなったりすることに気付いていない可能性があります。 (まだ!) ASLR と非 ASLR をサポートする Windows バージョンが混在する顧客基盤を持っている開発者は、CVE レポートに応じて対応する必要があります。まったく同じバグが Windows 10 では悪用できないように見えても、Windows XP では簡単に悪用できる可能性があります。 Windows 10 と Windows 8.1 または 7 の比較にも同じことが当てはまります。バージョンごとに ASLR の機能が向上しているためです。

要点 1.2: 優先ロード アドレスに関する誤った考えがないか、レガシー ソフトウェア コード ベースを監査します。

レガシ ソフトウェアは、Microsoft Visual C++ 6 などの古いツールで引き続き維持される場合があります。これらの開発ツールには、優先ロード アドレスの役割と重要性に関する古いドキュメントが含まれています。これらの古いツールはイメージを ASLR 互換としてマークすることができないため、デフォルトの DLL アドレスをわざわざ変更しない「怠惰な」開発者の方が実際には良いでしょう。

事実 2: Windows は、複数のプロセス間、さらには複数のユーザー間で、同じ場所にあるイメージの複数のインスタンスを読み込みます。すべてのイメージの新しいランダム ベース アドレスを保証できるのは、再起動のみです。

ASLR の Linux 実装で使用される ELF イメージは、位置に依存しない実行可能ファイルと共有ライブラリの位置に依存しないコードを使用して、起動のたびにメイン プログラムとそのすべてのライブラリに新たにランダム化されたアドレス空間を提供し、同じマシン コードを共有できます。異なるアドレスにロードされている場合でも、複数のプロセス間で。 Windows ASLR はこの方法では機能しません。代わりに、各 DLL または EXE イメージは、最初に使用されるときにカーネルによってランダムなロード アドレスが割り当てられ、DLL または EXE の追加のインスタンスがロードされると、同じロード アドレスを受け取ります。イメージのすべてのインスタンスがアンロードされ、その後そのイメージが再度ロードされた場合、イメージは同じベース アドレスを受け取る場合と受け取らない場合があります。事実 4 を参照してください。システム全体のすべてのイメージの新しいベース アドレスを保証できるのは、再起動のみです。

Windows DLL は位置に依存しないコードを使用しないため、コードをプロセス間で共有できる唯一の方法は、常に同じアドレスにロードすることです。これを実現するために、カーネルはアドレス (たとえば、32 ビット システムでは 0x78000000) を選択し、そのすぐ下のランダム化されたアドレスで DLL のロードを開始します。プロセスが最近使用された DLL をロードした場合、システムは以前に選択されたアドレスを再利用するだけで、メモリ内のその DLL の以前のコピーを再利用する可能性があります。この実装により、各 DLL にランダムなアドレスを提供し、DLL が同時に重複しないようにするという問題が解決されます。

EXE の場合、同じプロセスにロードされることはないため、2 つの EXE が重複する心配はありません。イメージが 0x100000 バイトより大きい場合でも、EXE の最初のインスタンスを 0x400000 に、2 番目のインスタンスを 0x500000 にロードしても問題はありません。 Windows は、特定の EXE の複数のインスタンス間でコードを共有することを選択するだけです。

要点 2.1: クラッシュ後に自動的に再起動する Windows プログラムは、ASLR を克服するためのブルート フォース攻撃の影響を特に受けやすくなります。

CGI プログラムなど、リモートの攻撃者がオンデマンドで実行できるプログラムや、スーパーサーバー (たとえば、inetd など) が必要な場合にのみ実行する接続ハンドラーを考えてみましょう。クラッシュ時にサービスを再起動するウォッチドッグとペアになっている Windows サービスは、別の可能性です。攻撃者は、Windows ASLR の仕組みに関する知識を利用して、EXE が読み込まれる可能性のあるベース アドレスを使い果たす可能性があります。プログラムがクラッシュし、(1) プログラムの別のコピーがメモリに残っている場合、または (2) プログラムがすぐに再起動し、場合によっては可能であれば、同じ ASLR ベース アドレスを受け取った場合、攻撃者は新しいインスタンスが引き続き使用されると想定できます。同じアドレスにロードされ、攻撃者は最終的に同じアドレスを試します。

要点 2.2: 攻撃者が任意のプロセスで DLL がロードされている場所を発見できる場合、攻撃者はすべてのプロセスで DLL がロードされている場所を知っています。

バグのある 2 つのネットワーク サービスを実行しているシステムを考えてみましょう。1 つはデバッグ メッセージでポインタ値をリークするがバッファ オーバーフローはなく、もう 1 つはバッファ オーバーフローはあるがポインタをリークしないサービスです。リーキーなプログラムが kernel32.dll のベース アドレスを明らかにし、攻撃者がその DLL 内のいくつかの有用な ROP ガジェットを知っている場合、同じメモリ オフセットを使用して、オーバーフローを含むプログラムを攻撃できます。したがって、一見無関係に見える脆弱なプログラムを連鎖させて、最初に ASLR を克服し、次にエクスプロイトを開始することができます。

要点 2.3: 権限昇格のエクスプロイトの最初のステップとして、権限の低いアカウントを使用して ASLR を克服できます。

バックグラウンド サービスが、ローカル ユーザーのみがアクセスできる名前付きパイプを公開し、バッファ オーバーフローが発生したとします。攻撃者は、メイン プログラムのベース アドレスとそのプロセスの DLL を特定するために、デバッガーで別のコピーを起動するだけです。デバッガーから決定されたオフセットを使用して、高い特権を持つプロセスを悪用するペイロードを開発できます。これは、EXE および DLL のランダムなベース アドレスを保護する際に、Windows がユーザーを互いに分離しようとしないために発生します。

事実 3: 32 ビット プログラムを 64 ビット プログラムに再コンパイルすると、ASLR がより効果的になります。

Windows の 64 ビット リリースは 10 年以上にわたって主流でしたが、32 ビットのユーザー空間アプリケーションは依然として一般的です。一部のプログラムは、Web ブラウザーの場合のように、サードパーティのプラグインとの互換性を維持する必要があります。また、開発チームは、プログラムに必要なメモリは 4 GB よりはるかに少ないため、32 ビット コードの方がスペース効率が高いと考えている場合もあります。 Visual Studio でさえ、64 ビット アプリケーションのビルドをサポートした後、しばらくの間32 ビット アプリケーションのままでした。

実際、32 ビット コードから 64 ビット コードに切り替えると、小さいながらも目に見えるセキュリティ上の利点が得られます。その理由は、32 ビット アドレスをランダム化する機能が制限されているためです。その理由を理解するには、図 1 で 32 ビットの x86 メモリ アドレスがどのように分類されるかを観察してください。詳細については、「物理アドレスの拡張」を参照してください。

オペレーティング システムは、アドレスの任意のビットを単純にランダム化することはできません。ページ部分 (ビット 0 から 11) 内のオフセットをランダム化すると、プログラムがデータの位置合わせについて行う前提が崩れます。ページ ディレクトリ ポインター (ビット 30 および 31) は変更できません。これは、ビット 31 がカーネル用に予約されており、ビット 30 が 2GB を超える RAM をアドレス指定するためのバンク切り替え手法として物理アドレス拡張によって使用されるためです。これにより、32 ビット アドレスのうち 14 ビットがランダム化の対象外になります。

実際、Windows は 32 ビット アドレスの 8 ビットのみをランダム化しようとします。これらはビット 16 ～ 23 で、アドレスのページ ディレクトリ エントリとページ テーブル エントリ部分にのみ影響します。その結果、ブルート フォースの状況では、攻撃者は 256 回の推測で EXE のベース アドレスを推測できる可能性があります。

ASLR を 64 ビット バイナリに適用すると、Windows はアドレスの 17 ～ 19 ビットをランダム化できます (DLL か EXE かによって異なります)。図 2 は、考えられるベース アドレスの数とそれに応じて必要なブルート フォース推測の数が 64 ビット コードで劇的に増加する様子を示しています。これにより、エンドポイント保護ソフトウェアまたはシステム管理者が、攻撃が成功する前に攻撃を検出できる可能性があります。

要点 3.1: 信頼できないデータを処理する必要があるソフトウェアは、大量のメモリを使用する必要がない場合でも、ASLR を最大限に活用するために、常に 64 ビットとしてコンパイルする必要があります。

ブルート フォース攻撃では、ASLR は 64 ビット プログラムへの攻撃を、まったく同じプログラムの 32 ビット バージョンへの攻撃よりも少なくとも 512 倍困難にします。

要点 3.2: 64 ビットの ASLR でさえブルート フォース攻撃の影響を受けやすく、防御側はブルート フォース攻撃を検出するか、実行可能な状況を回避することに集中する必要があります。

攻撃者が、脆弱なシステムに対して 1 秒あたり 10 回のブルート フォース試行を行うことができるとします。複数のインスタンスが実行されているためにターゲット プロセスが同じアドレスに留まるという一般的なケースでは、攻撃者は 32 ビット プログラムのベース アドレスを 1 分未満で発見し、64 ビット プログラムのベース アドレスを数時間で発見します。 64 ビット ブルート フォース攻撃はさらに多くのノイズを生成しますが、管理者またはセキュリティ ソフトウェアはそれに気づき、対処する必要があります。 ASLR をより効果的にするために 64 ビット ソフトウェアを使用することに加えて、システムはクラッシュ プロセスの再生成を回避する (ベース アドレスを発見するために攻撃者に「2 回目の攻撃」を与えることを避けるため) か、強制的に再起動する必要があります。プロセスが数回以上クラッシュした後の新しいアドレス空間。

要点 3.3: 32 ビット バージョンと 64 ビット バージョンの両方で利用可能なプログラムに対する概念実証攻撃を開発している研究者は、最初に 32 ビット バージョンに焦点を当てる必要があります。

32 ビット ソフトウェアが適切である限り、プログラムの 32 ビット バリアントに対する概念実証攻撃は、より簡単かつ迅速に開発できる可能性があります。結果として生じる攻撃は、より実行可能で説得力があり、ベンダーがプログラムにパッチを当てるのを早める可能性があります。

事実 4: Windows 10 はランダム化されたベース アドレスを Windows 7 よりも積極的に再利用するため、状況によっては脆弱になる可能性があります。

Windows システムが 1 つの DLL または EXE の複数のインスタンスがすべて同じベース アドレスにロードされることを保証する必要がある場合でも、DLL または EXE の最後のインスタンスがアンロードされると、システムはベース アドレスを追跡する必要がないことに注意してください。 DLL または EXE が再度読み込まれると、新しいベース アドレスを取得できます。

これは、Windows 7 での作業で観察された動作です。Windows 10 では動作が異なる場合があります。 DLL または EXE の最後のインスタンスがアンロードされた後でも、少なくとも短期間は同じベース アドレスを維持する場合があります (DLL よりも EXE の場合)。これは、マルチプロセス デバッガーでコマンドライン ユーティリティを繰り返し起動したときに発生することがあります。ただし、ユーティリティを新しいファイル名にコピーして起動すると、新しいベース アドレスを受け取ります。同様に、十分な期間が経過すると、ユーティリティは別のベース アドレスにロードされます。もちろん、再起動すると、すべての DLL と EXE の新しいベース アドレスが生成されます。

要点 4.1: Windows ASLR の保証について、ブートごとのランダム化を超えて想定しないでください。

特に、特定の EXE または DLL の最初のインスタンスが読み込まれるたびに、新しいアドレス空間をランダム化する Windows 7 の動作に依存しないでください。特にブルート フォース攻撃が 256 回以下の推測しかできない 32 ビット プロセスの場合は、Windows が本質的に ASLR に対するブルート フォース攻撃から保護されていると想定しないでください。

事実 5: Windows 10 はより積極的に ASLR を適用しており、さらに ASLR 互換としてマークされていない EXE や DLL にも適用しており、これにより ASLR がより強力になる可能性があります。

Windows Vista と 7 は、ASLR をサポートする最初の 2 つのリリースであったため、互換性を優先するためにいくつかのトレードオフが行われました。具体的には、これらの古い実装では、ASLR 互換としてマークされていないイメージに ASLR を適用せず、ASLRが 4 GB 境界を超えてアドレスをプッシュすることを許可しません。イメージが ASLR にオプトインしていない場合、これらの Windows バージョンは優先ベース アドレスを引き続き使用します。

Microsoft の Enhanced Mitigation Experience Toolkit (一般に EMET として知られている) を使用して Windows 7 をさらに強化し、ASLR 互換としてマークされていないイメージに対してもASLR をより積極的に適用することができます。 Windows 8 では、 ASLR を ASLR と互換性のないイメージに適用し、ヒープ割り当てをより適切にランダム化し、64 ビット イメージのエントロピーのビット数を増やすための機能が追加されました。

要点 5.1: ソフトウェア プロジェクトが正しいリンカー フラグを使用して ASLR の最も積極的な実装を選択していること、および ASLR を弱めるリンカー フラグを使用していないことを確認します。

表 2 を参照してください。リンカー フラグは、ASLR がイメージに適用される方法に影響を与える可能性があります。 Visual Studio 2012 以降では、✔️フラグが既定で既に有効になっており、🚫フラグが使用されない限り、最適な ASLR 実装が使用されることに注意してください。おそらく互換性の理由から、Visual Studio 2010 以前を使用している開発者は、リンカーがサポートしているフラグと既定で有効になっているフラグを確認する必要があります。

表 2: リンカー フラグは、ASLR がイメージに適用される方法に影響を与える可能性があります

要点 5.2: 必須の ASLR とボトムアップのランダム化を有効にします。

Windows 8 および 10 には、ASLR 互換としてマークされていないイメージで ASLR を強制的に有効にし、リベースされたイメージがランダムなベース アドレスを取得するように仮想メモリの割り当てをランダム化するオプション機能が含まれています。これは、EXE が ASLR 互換であるが、使用する DLL の 1 つが互換でない場合に役立ちます。防御側は、これらの機能を有効にして ASLR をより広く適用できるようにする必要があります。重要なことは、ASLR と互換性のない残りのソフトウェアを検出して、アップグレードまたは置き換えできるようにすることです。

事実 6: ASLR は実行可能イメージ全体を 1 つの単位として再配置します。

ASLR は、ランダム オフセットを選択し、それをイメージ内のすべてのアドレスに適用することで、実行可能イメージを再配置します。つまり、次のようになります。

• EXE 内の 2 つの関数がアドレス 0x401000 と 0x401100 にある場合、イメージが再配置された後でも、それらは 0x100 バイト離れたままになります。 x86 コードでは相対呼び出しと jmp 命令が普及しているため、これは明らかに重要です。同様に、0x401000 の関数は、イメージのベース アドレスから 0x1000 バイトのままになります。
• 同様に、2 つの静的変数またはグローバル変数が画像内で隣接している場合、ASLR が適用された後も隣接したままになります。
• 逆に、スタック変数とヒープ変数、およびメモリ マップト ファイルはイメージの一部ではなく、どのベース アドレスが選択されたかに関係なく、自由にランダム化できます。

要点 6.1: 実行可能イメージ内の 1 つのポインターがリークしただけで、イメージ全体のランダム化されたアドレスが公開される可能性があります。

ASLR の最大の制限と煩わしさの 1 つは、イメージ内のポインターをリークするデバッグ ログ メッセージやスタック トレースなどの一見無害な機能がセキュリティ バグになることです。攻撃者が同じプログラムまたは DLL のコピーを持っていて、それをトリガーして同じリークを生成できる場合、攻撃者は ASLR ポインターと ASLR 前のポインターの差を計算して、ASLR オフセットを特定できます。次に、攻撃者はそのオフセットを攻撃ペイロードのすべてのポインターに適用して、ASLR を克服できます。防御側は、ポインター開示の脆弱性についてソフトウェア開発者をトレーニングして、この問題の重大性を認識し、ソフトウェア開発ライフサイクルの一部としてこれらの脆弱性についてソフトウェアを定期的に評価する必要があります。

要点 6.2: 一部の種類のメモリ破損の脆弱性は、ASLR で保護できる範囲外にあります。

すべてのメモリ破損の脆弱性がリモート コード実行を直接達成する必要があるわけではありません。ネットワークから信頼されていないデータを受信するためのバッファ変数と、メモリ内のその直後にあるフラグ変数を含むプログラムを考えてみましょう。フラグ変数には、ユーザーがログインしているかどうか、およびユーザーが管理者であるかどうかを指定するビットが含まれています。プログラムが受信バッファの末尾を超えてデータを書き込むと、「フラグ」変数が上書きされ、攻撃者がログイン フラグと is-admin フラグの両方を設定する可能性があります。攻撃者はメモリ アドレスを認識したり書き込んだりする必要がないため、ASLR は攻撃を阻止しません。別の強化技術 (コンパイラの強化フラグなど) が変数を並べ替えた場合、またはプログラム内のすべての変数の場所を個別に移動した場合にのみ、そのような攻撃はブロックされます。

結論

アドレス空間レイアウトのランダム化は、メモリ破損のエクスプロイトに対する防御の中核です。この投稿では、Windows に実装された ASLR の歴史について説明し、Windows 実装のいくつかの機能と制限についても説明します。この投稿を確認することで、防御側は、Windows で利用可能な ASLR やその他の機能を最大限に活用してより積極的に適用するプログラムを構築する方法についての洞察を得ることができます。攻撃者は、ブートごとにのみ適用されるアドレス空間のランダム化や、イメージ全体を 1 つのユニットとして再配置するランダム化など、ASLR の制限を利用して、ブルート フォース攻撃やポインター リーク攻撃を使用して ASLR を克服できます。