アドレス空間レイアウトのランダム化

アドレス空間レイアウトのランダム化( ASLR ) は、メモリ破損の脆弱性の悪用を防ぐためのコンピュータセキュリティ技術です。^[1]攻撃者がコード実行をメモリ内の特定の悪用された機能などに確実にリダイレクトするのを防ぐために、ASLR は、実行可能ファイルのベースやスタック、ヒープ、ライブラリの位置など、プロセスの主要なデータ領域のアドレス空間位置をランダムに配置します。

Linux PaXプロジェクトは、最初に「ASLR」という用語を作り出し、2001 年 7 月にLinux カーネルのパッチとしてASLR の最初の設計と実装を公開しました。これは完全な実装と見なされ、2002 年 10 月以降、カーネル スタックのランダム化のパッチを提供しています。^[2]

ASLRをデフォルトでサポートした最初の主流のオペレーティングシステムは、2003年のOpenBSDバージョン3.4であり、^{[3] [4]} 2005年にはLinuxがそれに続きました。

アドレス空間のランダム化により、攻撃者がターゲット アドレスを予測することがより困難になり、一部の種類のセキュリティ攻撃が阻止されます。たとえば、return-to-libc 攻撃を実行しようとする攻撃者は、実行するコードを見つける必要がありますが、スタックに挿入されたシェルコードを実行しようとする他の攻撃者は、まずスタックを見つける必要があります。どちらの場合も、システムは関連するメモリ アドレスを攻撃者の観点から予測不可能にします。これらの値は推測する必要があり、推測が間違っていると、通常はアプリケーションがクラッシュして回復できません。

アドレス空間レイアウトのランダム化は、ランダムに配置された領域の位置を攻撃者が推測する可能性が低いことに基づいています。検索空間を増やすと、セキュリティが向上します。したがって、ランダム オフセットにエントロピーが多いほど、アドレス空間のランダム化は効果的です。エントロピーは、ランダム化が行われる仮想メモリ領域スペースの量を増やすか、ランダム化が行われる期間を短縮することで増加します。通常、期間は可能な限り短く実装されるため、ほとんどのシステムでは VMA 空間のランダム化を増やす必要があります。

ランダム化を破るには、攻撃者は攻撃したいすべての領域の位置を正しく推測する必要があります。カスタム コードや有用なデータをロードできるスタックやヒープなどのデータ領域では、コードにNOP スライドを使用したり、データの繰り返しコピーを使用したりすることで、複数の状態を攻撃できます。これにより、領域が少数の値のいずれかにランダム化されている場合に攻撃が成功します。対照的に、ライブラリ ベースやメイン実行可能ファイルなどのコード領域は正確に検出する必要があります。これらの領域は、スタック フレームがスタックに挿入され、ライブラリが返されるなど、 混在していることがよくあります。

次の変数を宣言できます。

• ${\displaystyle E_{s}}$(スタックトップのエントロピービット)
• ${\displaystyle E_{m}}$(ベースのエントロピービットmmap())
• ${\displaystyle E_{x}}$(メイン実行可能ベースのエントロピー ビット)
• ${\displaystyle E_{h}}$(ヒープベースのエントロピー ビット)
• ${\displaystyle A_{s}}$(スタック エントロピーの試行あたりの攻撃ビット数)
• ${\displaystyle A_{m}}$mmap()(基本エントロピーの試行あたりの攻撃ビット数)
• ${\displaystyle A_{x}}$(メイン実行可能ファイルのエントロピーの試行あたりの攻撃ビット数)
• ${\displaystyle A_{h}}$(ヒープベースエントロピーの試行あたりの攻撃ビット数)
• ${\displaystyle \alpha }$（試みられた）
• ${\displaystyle N}$(エントロピーの総量: )${\displaystyle N=(E_{s}-A_{s})+(E_{m}-A_{m})+(E_{x}-A_{x})+(E_{h}-A_{h})\,}$

攻撃者が成功する確率を計算するには、シグネチャベースの IPS、法執行機関、またはその他の要因によって中断されることなく実行される試行回数αを想定する必要があります。ブルート フォースの場合、デーモンを再起動することはできません。関連するビットの数と、各試行で攻撃されるビットの数も計算する必要があり、攻撃者が破らなければならないビットの数も残ります。

次の式は、 Nビットのエントロピーに対するα 回の試行の特定のセットの成功確率を表します。

• ${\displaystyle g\left(\alpha \,\right)=1-{\left(1-{2^{-N}}\right)^{\alpha }\,}\,{\text{ if }}0\leq \,\alpha \,}$(分離された推測。アドレス空間は各試行後に再ランダム化されます)
• ${\displaystyle b\left(\alpha \,\right)={\frac {\alpha \,}{2^{N}}}\,{\text{ if }}0\leq \,\alpha \,\leq \,{2^{N}}}$(同じアドレス空間を持つプログラムのコピーに対する体系的なブルートフォース攻撃)

多くのシステムでは、数千から数百万になることがあります。32 ビット システムでは、エントロピーNの一般的な量は 8 ビットです。^[5] 2004 年のコンピュータ速度について、Shacham と同僚は「... 16 ビットのアドレス ランダム化は、ブルート フォース攻撃によって数分以内に破られる可能性があります」と述べています。 ^[6] (著者の声明は、同じアプリケーションを遅延なく複数回攻撃できる能力に依存しています。grsecurity に含まれるような ASLR の適切な実装では、このようなブルー​​ト フォース攻撃を実行不可能にするいくつかの方法が提供されています。1 つの方法は、実行ファイルが特定の回数クラッシュした場合、構成可能な時間の間実行されないようにすることです。) 最新の64 ビットシステムでは、これらの数値は通常、少なくとも数百万に達します。^{[引用が必要]}${\displaystyle 2^{N}}$^[update]

Android ^{[7] [非一次ソースが必要]}およびおそらく他のシステム^{[は？ ]は、ライブラリのロード順序をランダム化する ASLR の一種である}Library Load Order Randomization を実装しています。これにより、ライブラリがロードされる順序がランダム化されます。これにより提供されるエントロピーは非常に少なくなります。必要なライブラリごとに提供されるエントロピーのビット数の概算を以下に示します。これは、さまざまなライブラリ サイズを考慮していないため、実際に得られるエントロピーは実際にはいくらか高くなります。攻撃者に必要なのは通常、1 つのライブラリだけです。複数のライブラリの場合は計算がより複雑になり、以下に示すようになります。攻撃者が 1 つのライブラリのみを使用する場合は、のより複雑な式を簡略化したものです。 ${\displaystyle l=1}$

• l (ロードされたライブラリの数)
• β（攻撃者が使用するライブラリの数）
• ${\displaystyle E_{m}={\begin{cases}\log _{2}\left(l\right)&{\text{ if }}\beta \,=1,l\geq \,1\\\sum _{i=l}^{l-\left(\beta \,-1\right)}\log _{2}\left(i\right)&{\text{ if }}\beta \,\geq \,1,l\geq \,1\end{cases}}}$

これらの値はlの値が大きい場合でも低くなる傾向があります。最も重要なのは、攻撃者は通常C 標準ライブラリしか使用できないため、 と想定できることが多いためです。ただし、少数のライブラリであっても、ここでは数ビットのエントロピーが得られます。したがって、ライブラリのロード順序のランダム化と VMA アドレスのランダム化を組み合わせて、数ビットのエントロピーをさらに得ることは興味深い可能性があります。これらの余分なエントロピーは、他の mmap() セグメントには適用されず、ライブラリにのみ適用されます。 ${\displaystyle \beta \,=1}$

攻撃者は、単純な情報漏洩から、攻撃ごとに複数ビットのエントロピーを攻撃する (ヒープスプレーなど) まで、さまざまな方法を使用して、ランダム化されたアドレス空間に存在するエントロピーを削減する可能性があります。これに対してできることはほとんどありません。

フォーマット文字列の脆弱性を利用すると、メモリレイアウトに関する情報が漏洩する可能性があります。printf などのフォーマット文字列関数は、可変引数リストを使用して機能し、フォーマット指定子は引数リストの外観を記述します。引数が渡される一般的な方法により、各フォーマット指定子はスタック フレームの最上部に近づきます。最終的には、戻りポインターとスタック フレーム ポインターを抽出して、脆弱なライブラリのアドレスと既知のスタック フレームのアドレスを明らかにすることができます。これにより、ライブラリとスタックのランダム化が攻撃者にとっての障害となることを排除できます。

スタックまたはヒープ内のエントロピーを減らすこともできます。スタックは通常 16 バイトに揃える必要があるため、これが最小のランダム化間隔となります。一方、ヒープはページ揃えする必要があり、通常は 4096 バイトです。攻撃を試みるとき、重複した攻撃をこれらの間隔に揃えることができます。シェルコード インジェクションではNOP スライドを使用できます。また、システムに戻るときに、文字列 ' ' を任意の数のスラッシュ/bin/sh' ' に置き換えることができます。削除されるビット数は、攻撃されたn間隔とまったく同じです。 ////////bin/sh${\displaystyle \log _{2}\!\left(n\right)}$

このような減少はスタックまたはヒープ内のデータ量によって制限されます。たとえば、スタックは通常、8MB  ^{[8]からさらに小さくなり}、最大で19ビットですが、より控えめな見積もりでは8〜4に対応する10ビット16KB  ^[8]のスタック詰め。一方、ヒープはメモリアロケータの動作によって制限されます。glibcの場合、128KBを超える割り当てはmmapを使用して作成され、攻撃者は5ビットの削減に制限されます。これはブルートフォース攻撃の際の制限要因でもあります。実行する攻撃の数は減らすことができますが、攻撃の規模が大きくなり、状況によっては侵入検知システムに動作が明らかになる可能性があります。

ASLR で保護されたアドレスは、さまざまなサイド チャネルによって漏洩される可能性があり、緩和策の有用性が失われます。最近の攻撃では、CPU の分岐ターゲット予測バッファー (BTB) またはメモリ管理ユニット (MMU) のウォーキング ページ テーブルによって漏洩された情報が使用されています。このクラスの ASLR 攻撃が緩和できるかどうかは明らかではありません。緩和できない場合、ASLR の利点は減少するか、なくなります。

2024年8月には、Linux、macOS、Windowsなどの主要なデスクトッププラットフォームの実証分析をまとめた論文^[9]が発表されました。この研究では、さまざまなプロセス、スレッド、システムの再起動におけるメモリオブジェクトの配置のばらつきを調べています。その結果、2024年時点でLinuxディストリビューションなどの一部のシステムは堅牢なランダム化を提供している一方で、WindowsやmacOSなどの他のシステムは実行コードやライブラリなどの重要な領域を適切にランダム化できないことが多いことがわかりました。さらに、Linux 5.18バージョン以降ではライブラリのエントロピーが大幅に減少していることが判明し、攻撃者が悪用の複雑さを大幅に軽減するために活用できる相関パスが特定されています。

いくつかの主流の汎用オペレーティング システムは ASLR を実装しています。

Android 4.0 Ice Cream Sandwich は、メモリ管理の問題によるエクスプロイトからシステムとサードパーティのアプリケーションを保護するために、アドレス空間レイアウトのランダム化 (ASLR) を提供します。位置独立実行可能ファイルのサポートは Android 4.1 で追加されました。^[10] Android 5.0 では非 PIE サポートが廃止され、すべての動的リンクバイナリが位置独立であることが要求されました。^{[11] [12]}ライブラリのロード順序のランダム化は、2015 年 10 月 26 日に Android オープンソース プロジェクトに受け入れられ、^{[7] [非プライマリソースが必要]}、Android 7.0 リリースに含まれました。

DragonFly BSDには、 2010年に追加されたOpenBSDのモデルに基づいたASLRの実装があります。^[13] これはデフォルトではオフになっていますが、sysctl vm.randomize_mmapを1に設定することで有効にできます。

ASLRのサポートはFreeBSD 13.0で登場しました。^{[14] [15]} 13.2以降ではデフォルトで有効になっています。^[16]

AppleはiOS 4.3（2011年3月リリース）でASLRを導入した。 ^[17]

KASLRはiOS 6で導入されました。^[18] ランダム化されたカーネルベースは で0x01000000 + ((1+0xRR) * 0x00200000)、 は0xRRiBoot（第2段階のiOSブートローダ）によって生成されたSHA1（ランダムデータ）からのランダムバイトです。^[19]

Linuxカーネルは、2005年6月にリリースされたカーネルバージョン2.6.12以降、デフォルトで弱い形式のASLRを有効にしています。 ^[20] LinuxカーネルのPaXおよびExec Shieldパッチセットは、より完全な実装を提供します。LinuxのExec Shieldパッチは、16バイト周期で19ビットのスタックエントロピーと、4096バイトの1ページ周期で8ビットのmmapベースランダム化を提供します。これにより、スタックベースは524,288の位置を含む8MB幅の領域に配置され、mmapベースは256の位置を含む1MB幅の領域に配置されます。

ASLRは、を使用して実行ドメインを変更することで、特定のプロセスに対して無効にすることができますpersonality(2)。^[21] sysctlオプションの多くは、メインラインASLRの動作を制御します。たとえば、は何をkernel.randomize_va_spaceランダム化するかを制御します。最も強力なオプションは2です。mmapに対してランダム化するビット数を制御します。^[22]vm.mmap_rnd_bits

位置独立実行可能ファイル(PIE) は、メインの実行可能バイナリのランダム ベース アドレスを実装し、2004 年 4 月 18 日から導入されています。これにより、共有ライブラリに使用されるのと同じアドレス ランダム性がメインの実行可能ファイルに提供されます。PIE 機能は、同じ実行可能ファイルに対してprelink機能と一緒に使用することはできません。prelink ツールは、実行時ではなく prelink 時にランダム化を実装します。これは、prelink の設計上、動的リンカーがライブラリの再配置を行う前にライブラリの再配置を処理することを目的としているためです。これにより、プログラムの複数回の実行に対して再配置が 1 回で済みます。結果として、実際のアドレス空間のランダム化は prelink の目的に反します。

2014年、Marco-GisbertとRipollは、 PIE実行可能ファイルに対するLinux ASLRを弱めるoffset2lib技術を公開した。Linuxカーネルは、ライブラリの直後にPIE実行可能ファイルをロードするため、実行可能ファイルとライブラリ関数の間には固定オフセットが存在する。攻撃者が実行可能ファイル内の関数のアドレスを見つける方法を見つけた場合、ライブラリアドレスも判明する。彼らは、400回未満の試行でアドレスを見つける攻撃を実証した。彼らは、randomize_va_space=3ライブラリに対する実行可能ファイルの配置をランダム化する新しいオプションを提案したが^[5]、 2024年現在、まだアップストリームに組み込まれていない。^[23]

2022 年 5 月にリリースされた Linux カーネル 5.18 では、32 ビットと 64 ビットの両方の実装の有効性が低下しました。Linux ファイルシステムは、thp_get_unmapped_areaファイル バックアップmmapに応答するために を呼び出します。5.18 の変更により、2 MiB を超えるファイルは 2 MiB 境界に揃えられたアドレスを返すようになり、潜在的に巨大ページでバックアップされる可能性があります。(以前は、境界の拡大は Direct Access (DAX) マッピングにのみ適用されていました。) 一方、C ライブラリ (libc) は時間の経過とともにサイズが大きくなり、この 2 MiB のしきい値を超えたため、これらのライブラリは以前のように (通常は) 4 KiB ページ境界に揃えられるのではなく、2 MiB に揃えられるようになりました。つまり、エントロピーが 9 ビット失われます。32 ビット Linux の場合、多くのディストリビューションでは、 libc の配置にまったくランダム化が見られません。64 ビット Linux の場合、28 ビットのエントロピーが 19 ビットに削減されます。これに応じて、Ubuntuは設定を増やしましたmmap_rnd_bits。^[24] Martin Douchaは、この問題を検出するためのLinux Test Projectテストケースを追加しました。^[25]

カーネルアドレス空間レイアウトランダム化（KASLR）は、起動時にカーネルコードが配置される場所をランダム化することで、Linuxカーネルイメージのアドレス空間ランダム化を可能にします。^[26] KASLRは、2014年3月30日にリリースされたカーネルバージョン3.14でLinuxカーネルメインラインに統合されました。[ ^27]コンパイル時に、カーネルのブートパラメータの1つとしてnokaslrを指定することにより、起動時に無効にすることができます。^[28]

x86プロセッサにはカーネルアドレスを漏洩する可能性のあるサイドチャネル攻撃がいくつかあります。 ^{[29] [30]} 2017年後半には、これらの攻撃を阻止するためにカーネルページテーブル分離（KPTI、別名KAISER）が開発されました。^{[31] [32]しかし、この方法では}分岐予測構造の衝突を利用したサイドチャネル攻撃から保護することはできません。^[33]

2021年現在^[update]、より細かい粒度のカーネルアドレス空間レイアウトランダム化（または関数粒度KASLR、FGKASLR）は、関数レベルまでランダム化するためにKASLRを拡張する計画です。^[34]

MicrosoftのWindows Vista（2007年1月リリース）以降では、ASLRが有効になっているのは、 ASLRが有効になるように明示的にリンクされた実行可能ファイルとダイナミックリンクライブラリに対してのみです。 ^[35]互換性のため、他のアプリケーションではデフォルトでは有効になっていません。通常、互換性がないのは古いソフトウェアのみで、レジストリエントリを編集するかHKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages、^{[36] Microsoftの}Enhanced Mitigation Experience ToolkitをインストールすることでASLRを完全に有効にすることができます。

ヒープ、スタック、プロセス環境ブロック、スレッド環境ブロックの位置もランダム化されます。シマンテックのセキュリティホワイトペーパーでは、32ビットWindows VistaのASLRは期待どおりに堅牢ではない可能性があると指摘されており、マイクロソフトはその実装に弱点があることを認めています。^[37]

WehnTrust ^[38]やOzone ^[39]などのホストベースの侵入防止システムも、 Windows XPおよびWindows Server 2003オペレーティングシステム用の ASLR を提供しています。WehnTrust はオープンソースです。^[40] Ozone の実装の詳細は不明です。^[41]

2012年2月に^[42]、Windows 8より前の32ビットWindowsシステム上のASLRは、メモリ不足の状況では効果が低下する可能性があることが指摘されました。同じ研究でLinuxでも同様の効果が得られました。テストコードによりMac OS X 10.7.3システムがカーネルパニックを起こしたため、このシナリオでのASLRの動作は不明のままでした。

ユーザーランドでのASLRのサポートはNetBSD 5.0（2009年4月リリース）で導入され、^[43] 2016年4月のNetBSD-currentではデフォルトで有効化されました。^[44]

amd64上のカーネルASLRサポートは2017年10月にNetBSD-currentに追加され、NetBSDはKASLRをサポートする最初のBSDシステムとなった。^[45]

2003年、OpenBSDは強力な形式のASLRをサポートし、デフォルトで有効化した最初の主流OSとなった。^{[3] OpenBSDは2008年に}PIEバイナリ のサポートを追加してASLRサポートを完了した。 ^[46] OpenBSD 4.4のmalloc(3)は、 OpenBSDのmmap システムコールの一部として実装されたASLRとギャップページ機能を利用してセキュリティを向上させ、use-after-freeバグを検出するように設計された。^{[47] 2013年にリリースされたOpenBSD 5.3は、複数の}ハードウェアプラットフォームで位置独立実行ファイルをデフォルトで有効化した最初の主流OSであり、OpenBSD 5.7は位置独立静的バイナリ（Static-PIE）をデフォルトで有効化した。^[46]

Mac OS X Leopard 10.5（2007年10月リリース）では、Appleはシステムライブラリのランダム化を導入しました。 ^[48]

Mac OS X Lion 10.7（2011年7月リリース）では、Appleは実装をすべてのアプリケーションに拡大し、「アドレス空間レイアウトのランダム化（ASLR）がすべてのアプリケーションで改善されました。これは32ビットアプリケーションでも利用可能になり（ヒープメモリ保護も同様）、64ビットおよび32ビットアプリケーションの攻撃に対する耐性が向上しました。」と述べています。^[49]

OS X Mountain Lion 10.8（2012年7月リリース）以降では、カーネルだけでなくkextやゾーンを含むシステム全体がシステム起動時にランダムに再配置されるようになりました。^[50]

ASLRはSolaris 11.1（2012年10月リリース）からSolarisに導入されました。Solaris 11.1のASLRはシステム全体、ゾーンごと、またはバイナリごとに設定できます。^[51]

ブランチターゲットバッファを利用したサイドチャネル攻撃は、 ASLR保護を回避することが実証されました。^[33] 2017年には、「ASLR⊕Cache」と呼ばれる攻撃が実証され、JavaScriptを使用してWebブラウザでASLRを破ることができました。^[52]

• バッファオーバーフロー
• スタックバッファオーバーフロー
• スタック破壊保護
• NXビット

• エクスプロイト緩和技術: 10 年後のアップデート 2014-02-20 にWayback MachineでアーカイブOpenBSD
• ASLR に関する PaX ドキュメント
• PaX と Exec Shield および W^X の比較
• Windows Vista におけるアドレス空間レイアウトのランダム化 - Michael Howard の Web ログ
• Windows 2000/XP/2003 用 ASLR (WehnTrust)
• PaX ASLR保護のバイパス
• アドレス空間レイアウトのランダム化の有効性について
• ASLR および DEP サポートについてアプリケーション (またはライブラリ) をテストする
• ASLR スマック＆ラフ リファレンス