アドレス空間配置ランダム化

アドレス空間配置のランダム化は、攻撃者がランダムに配置された領域の位置を推測する可能性が低いことに基づいています。セキュリティは、検索空間を拡大することで向上します。したがって、アドレス空間のランダム化は、ランダムオフセットにエントロピーが多いほど効果的です。エントロピーは、ランダム化が行われる仮想メモリ領域の空間量を増やすか、ランダム化が行われる期間を短縮することによって増加します。期間は通常、可能な限り短く実装されるため、ほとんどのシステムでは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}}}$（同じアドレス空間を持つプログラムのコピーに対して、体系的な総当たり攻撃を行う）

多くのシステムでは、$2N$数千から数百万になることもあります。32ビットシステムでは、典型的なエントロピーNの値は8ビットです。^{[ 6 ]} 2004年のコンピュータ速度に関して、Shachamらは「…16ビットのアドレスランダム化は、総当たり攻撃によって数分以内に 破られる可能性がある」と述べています。 ^{[ 7 ]}（著者らの主張は、同じアプリケーションを遅延なく複数回攻撃できるという前提に基づいています。grsecurityに含まれるようなASLRの適切な実装では、このような総当たり攻撃を不可能にするいくつかの方法が提供されています。1つの方法は、実行ファイルが一定回数クラッシュした場合に、設定可能な時間だけ実行を阻止することです。）64ビットシステムでは、これらの数値は通常、少なくとも数百万に達します。

Android ^{[ 8 ]}およびおそらく他のシステムでは、ライブラリのロード順序をランダム化する ASLR の一種であるライブラリロード順序ランダム化が実装されています。これはエントロピーをほとんど提供しません。必要なライブラリごとに提供されるエントロピーのビット数の近似値は以下に示されています。これはまださまざまなライブラリサイズを考慮していないため、実際に得られるエントロピーは実際にはもう少し高くなります。攻撃者は通常 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 標準ライブラリしか使用できないため、多くの場合、${\displaystyle \beta \,=1}$しかし、ライブラリの数が少なくても、ここで得られるエントロピーはわずかです。そのため、ライブラリのロード順序のランダム化とVMAアドレスのランダム化を組み合わせることで、さらにエントロピーを少し増やすことができる可能性があります。これらの追加エントロピーは、他のmmap()セグメントには適用されず、ライブラリにのみ適用されます。

ASLRで保護されたアドレスは、様々なサイドチャネル攻撃によって漏洩する可能性があり、その場合、ASLRによる保護の有効性が失われます。最近の攻撃では、CPUの分岐ターゲット予測バッファ（BTB）やメモリ管理ユニット（MMU）のページテーブルから漏洩した情報が利用されています。この種のASLR攻撃を緩和できるかどうかは明らかではありません。もし緩和できない場合、ASLRの利点は低下するか、あるいは完全に失われます。

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

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

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

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

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

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

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

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

位置独立実行可能ファイル(PIE) は、メイン実行可能バイナリにランダムなベースアドレスを実装するもので、2004 年 4 月 18 日から運用されています。これにより、共有ライブラリに使用されているものと同じアドレスのランダム性がメイン実行可能ファイルにも適用されます。PIE 機能は、同じ実行可能ファイルに対してプリリンク機能と併用することはできません。プリリンクツールは、実行時ではなくプリリンク時にランダム化を実装します。これは、プリリンクが動的リンカがライブラリの再配置処理を行う前に処理することを目的としており、再配置処理をプログラムの複数回の実行に対して一度だけ実行できるようにするためです。したがって、実際のアドレス空間のランダム化は、プリリンクの目的を損なうことになります。

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

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 は設定値を上げました。^{[ 25 ]} Martin Doucha は、この問題を検出するためにLinux Test Project のテストケースを追加しました。^{[ 26 ]}   mmap_rnd_bits

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

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

WehnTrust ^{[ 39 ]}やOzone ^{[ 40 ]}などのホストベースの侵入防止システムも、 Windows XPおよびWindows Server 2003オペレーティングシステム向けに ASLR を提供しています。WehnTrust はオープンソースです。^{[ 41 ]} Ozone の実装の詳細は公開されていません。^{[ 42 ]}

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

ユーザーランドでの ASLR のサポートはNetBSD 5.0 (2009 年 4 月リリース) で登場し、^{[ 44 ]} 2016 年 4 月の NetBSD-current ではデフォルトで有効になりました。^{[ 45 ]}

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

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

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

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

OS X Mountain Lion 10.8（2012年7月リリース）以降では、カーネル、kext、ゾーンを含むシステム全体がシステム起動時にランダムに再配置されます。^{[ 51 ]}

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