コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

「アドレス空間配置のランダム化」の版間の差分

出典: フリー百科事典『ウィキペディア(Wikipedia)』
削除された内容 追加された内容
Cewbot (会話 | 投稿記録)
102行目: 102行目:


=== Android ===
=== Android ===
[[Android]] 4.0 Ice Cream Sandwichはシステムとサードパーティーのアプリケーションをメモリ管理の問題に起因する脆弱性攻撃から保護するためのASLRを提供する。また、4.1においては[[位置独立コード#位置独立実行形式|位置独立実行ファイル (PIE)]] への対応が追加された<ref>{{cite web|title=Android Security|url=http://source.android.com/tech/security/index.html#memory-management-security-enhancements|publisher=Android Developers|accessdate=7 July 2012}}</ref>。
[[Android (オペレーティングシステム)|Android]] 4.0 Ice Cream Sandwichはシステムとサードパーティーのアプリケーションをメモリ管理の問題に起因する脆弱性攻撃から保護するためのASLRを提供する。また、4.1においては[[位置独立コード#位置独立実行形式|位置独立実行ファイル (PIE)]] への対応が追加された<ref>{{cite web|title=Android Security|url=http://source.android.com/tech/security/index.html#memory-management-security-enhancements|publisher=Android Developers|accessdate=7 July 2012}}</ref>。


== 関連項目 ==
== 関連項目 ==

2020年9月6日 (日) 06:51時点における版

アドレス空間配置のランダム化英語: address space layout randomization, ASLR)とは、重要なデータ領域 の位置(通常、プロセスアドレス空間における実行ファイルの基底とライブラリヒープ、およびスタックの位置が含まれる)を無作為に配置するコンピュータセキュリティの技術である。

利点

アドレス空間のランダム化は、攻撃者が標的のアドレスを予測することをより困難にすることによって、ある種のセキュリティ攻撃を妨害する。たとえば、return-to-libc攻撃で実行を試みる攻撃者は実行されるコードの位置を特定しなければならず、スタック上に注入されたシェルコードの実行を試みる他の攻撃者はまずスタックを見つけなければならない。どちらの場合も、関連するメモリアドレスは攻撃者から隠されている。攻撃者はこれらの値を推測しなくてはならず推測が失敗すると通常アプリケーションはクラッシュするため、回復は不可能である。

有効性

アドレス空間配置のランダム化はランダムに置かれた領域を攻撃者が見つける可能性の低さに依存している。探索空間が増大すれば、その分セキュリティも向上する。したがって、アドレス空間のランダム化は無作為なオフセット内に存在するエントロピーが大きくなるほど効果的である。エントロピーはランダム化が行われる仮想記憶領域空間の量を増やすか、ランダム化を行う時間間隔を短縮することによって増加する。時間間隔は通常可能な限り小さくなるよう実装されるので、ほとんどのシステムは仮想記憶領域の量を増やさなければならない。

ランダム化に対抗するため、攻撃者は攻撃を望む全ての領域の位置の推測を成功させなければならない。カスタムのコードや攻撃の役に立つデータを乗せることができる、スタックやヒープのようなデータ領域については、コードならばNOPスライドの使用、データならコピーの繰り返しによって、攻撃可能な状態を増やすことができる。領域がランダム化された結果それらの状態のどれか1つになれば攻撃は成功する。一方、ライブラリの基底やメイン実行ファイルのようなコード領域は正確に位置を知る必要がある。しばしばこれらの領域は混合される。たとえばスタックフレームはスタック上に注入され、ライブラリはそこを戻り先にされる。

まず、以下の変数を宣言する:

攻撃者が成功する確率を計算するために、試行回数 はシグネチャベースのIPS、法的規制、その他の要因によって中断されることなく実行されると仮定する。ブルートフォースの場合、デーモンを再起動することはできない。さらにどれだけ多くのビットが関係し、どれだけ多くのビットが1回あたりの試行で攻撃され、どれだけ多くのビット攻撃しなければならないビットが残るかも算出しなければならない。

以下の式はビットのエントロピーに対する回の試行が与えられたとき、攻撃が成功する確率を表す。

多くのシステムで、は数千から数百万の範囲になりうる。現代の 64ビットシステム上では、これらの数値は少なくとも数百万に達する。アドレスのランダム化に16ビットを使用する2004年時点の32ビットシステムについて、Shachamと共同研究者は以下のように述べている。「…16ビットのアドレスランダム化はブルートフォース攻撃により数分で破れる」[1] この研究者の主張は攻撃者が同じアプリケーションに対していかなる遅延もなく複数回攻撃できる能力に依存していることに注意されたい。grsecurityに含まれているような、ASLRの適切な実装は、このようなブルートフォース攻撃を不可能にするいくつかの手法を提供している。ひとつの方法は、ある一定の時間内に設定された回数以上クラッシュした実行ファイルの実行を妨げることである。

一部のシステムはライブラリロード順序のランダム化を実装する。これはライブラリがロードされる順序をランダム化する、ASLRの一形態である。これにより供給されるエントロピーはほとんどない。必要なライブラリ1つごとに供給されるエントロピーのビット数の見積りを以下に示す。これは可変のライブラリサイズを考慮に入れていないため、実際に得られるエントロピーはもう少し大きくなる。攻撃者は通常1つのライブラリしか必要としないことに注意されたい。複数ライブラリの場合の計算式はより複雑になるがこれも以下に示す。攻撃者が1つのライブラリしか使用しない場合は、複雑な式をとして単純化したものであることに注意。

これらの値はが大きな値でも、低くなる傾向にある。もっとも重要な点は、攻撃者は通常C標準ライブラリしか使えず、そのためしばしばと仮定できるということである。しかし、興味深いことにライブラリの数が少なくともここで数ビットのエントロピーが得られる。このようにライブラリロード順序のランダム化を仮想メモリ領域アドレスのランダム化と組み合わせることにより、数ビットの追加エントロピーを得られる可能性がある。これらの追加ビットはライブラリのみに適用され、他のmmap()セグメントなどには適用されないことに注意。

エントロピーの削減

攻撃者は単純な情報漏洩から、攻撃1回あたりの複数ビットエントロピー攻撃(heap sprayingによる攻撃など)まで、いくつかの方法を使ってランダム化されたアドレス空間に現れるエントロピーを削減できる。これに対してできることはほとんどない。

書式文字列攻撃を使用したメモリレイアウトに関する情報の漏洩がありうる。printf()のような書式文字列関数は可変長引数リストを使用して作業を行う。書式指定子は引数リストがどのように見えるかを記述する。引数が渡される通常の方法のために、各種書式指定子はスタックフレームの先頭近くに移動する。最終的に、戻り先のポインタとスタックフレームポインタの抽出が可能であり、脆弱なライブラリのアドレスと既知のスタックフレームのアドレスが現れる。これにより攻撃者に対する障害としてのライブラリとスタックのランダム化を完全に取り除ける。

スタックやヒープのエントロピーを減らすこともできる。スタックは通常16バイトの倍数境界に配置されなければならないので、ランダム化の間隔もそれより小さくにできない。さらにヒープはページ(通常4096バイト)境界に配置されなければならない。攻撃を試みるとき、重複した攻撃をこれらの境界に合わせることが可能である。NOPスライドをシェルコードの注入に使うことができ、system()への戻りを試みるときは文字列 '/bin/sh' を任意個数のスラッシュの '////////bin/sh' に置き換えることができる。削減されるビット数は間隔の攻撃に対して、ちょうどである。

このような減少はスタックやヒープのデータ量のために制限される。たとえば、スタックは通常8MB[2]に制限され、それよりも伸長はずっと少ない。これにより削減が可能なのは最大19ビットであるが、より保守的な見積もりでは4-16KB[2]のスタックの詰め物に対しておよそ 8-10ビットである。一方ヒープはメモリアロケータの振る舞いに制限される。glibcの場合、128KBを超える割り当てはmmap()を使って作られ、攻撃者のビット削減を5ビットに制限する。これはブルートフォースに対する制限要因でもある。行われる攻撃の回数を削減することはできるが、攻撃のサイズが十分大きくなると一部の環境での振る舞いは侵入検知システムと似たものになりうる。

歴史

PaXプロジェクトが最初に「ASLR」という造語を発明した。PaXはASLRの最初の設計と実装を 2001年7月に発行した。これは現在でも最も完全な実装であり、2002年10月からはカーネルスタックのランダム化も提供している。PaXは他の実装と比べて、各ランダム化されたレイアウトごとに最大のエントロピーを与える実装であり続けている[3]

実装

いくつかの主流の、汎用目的のオペレーティングシステムがASLRを実装している。

OpenBSD

OpenBSDはASLRをサポートした(そしてデフォルトで有効にした)、最初の主流のオペレーティングシステムの1つとなった[4]

Linux

Linuxは弱い[5]形のASLRを、カーネルバージョン2.6.12からデフォルトで有効にした。PaXExec ShieldのLinuxカーネルに対するパッチ集はより完全な実装を提供する。Adamantix、Alpine LinuxHardened Gentoo、およびHardened Linux From Scratchを含む各種のLinuxディストリビューションはPaXのASLR実装をデフォルトで備えている。

Linux用のExec Shieldパッチは16バイトの間隔上で19ビットのスタックエントロピーを供給する。そして4096バイトの1ページ間隔上で8ビットのmmap()エントロピーを供給する。これは524288通りの位置がありうる8MBの広さの領域にスタック基底を置く。そして256通りの位置がありうる1MBの広さの領域にmmap()基底を置く。

位置独立実行ファイル (PIE) の機能はメイン実行ファイルバイナリのランダムな基底アドレスを2003年から実装する。これはメイン実行ファイルに対して、共有ライブラリで使われるものと同じアドレスのランダム性を提供する。PIEの機能はネットワークに直接向き合うデーモンにのみ使われている - PIE機能は同じ実行ファイルでprelinkの機能と同時に使うことができない。

prelinkツールは実行時ではなくprelink時にランダム化を実装する。なぜならば仕様によりprelink は、動的リンカが行わなければならなくなる前にライブラリの再配置を行うことで、プログラムを何度も走らせても再配置が1回しか行われないようにすることが目的だからである。結果として、真のアドレス空間ランダム化はprelinkの目的を打ち消してしまう。

Microsoft Windows

マイクロソフトのWindows VistaWindows Server 2008Windows 7、およびWindows Server 2008 R2は、ASLRが有効となるよう特別にリンクされた実行ファイルとダイナミックリンクライブラリについてのみではあるが、デフォルトでASLRを有効にしている[6]。これにはService Pack 1より前のWindows Vista上のInternet Explorer 7が含まれていなかった。ASLRとDEPは両方がアプリケーション互換性の目的で無効にされていた[7]Internet Explorer 8を含む、より新しいバージョンはこれらの保護を有効にした。すべての実行ファイルとライブラリで強制的にASLRを有効または無効にするレジストリ設定が存在する。レジストリキー "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages" である[8]

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

WehnTrust[10]やOzone[11]のようなホストベースの侵入検知システムも、ASLRをWindows XPWindows Server 2003オペレーティングシステムに提供している。しかし、これらの実装の完全な詳細は公開されていない[12]

Solaris

Solaris 11.1 よりサポートされた[13]

macOS

アップルは、Mac OS X v10.5で一部のライブラリオフセットのランダム化を導入した[14]。この実装は、ASLRが防ぐことを目的とした攻撃に対する完全な保護を提供しない[15][16][17][18]

iOS (iPhone, iPod touch, iPad)

アップルは、iOS 4.3においてASLRを削除した。

Android

Android 4.0 Ice Cream Sandwichはシステムとサードパーティーのアプリケーションをメモリ管理の問題に起因する脆弱性攻撃から保護するためのASLRを提供する。また、4.1においては位置独立実行ファイル (PIE) への対応が追加された[19]

関連項目

出典

  1. ^ On the Effectiveness of Address-Space Randomization,Shacham, H. and Page, M. and Pfaff, B. and Goh, E.J. and Modadugu, N. and Boneh, D,Proceedings of the 11th ACM conference on Computer and communications security,pp 298--307, 2004
  2. ^ a b RAM、ROM、フラッシュメモリなどのトランジスタメモリとキャッシュサイズおよびファイルサイズはK (10241)、M (10242)、G (10243)、…を2進接頭辞として使う。
  3. ^ Comparison of PaX to ExecShield and W^X
  4. ^ Theo De Raadt (2005年). “Exploit Mitigation Techniques (updated to include random malloc and mmap) at OpenCON 2005”. 26 August 2009閲覧。
  5. ^ http://www.tomshardware.com/reviews/pwn2own-mac-hack,2254-4.html
  6. ^ http://msdn.microsoft.com/en-us/library/bb430720.aspx
  7. ^ MS08-078 and the SDL”. The Security Development Lifecycle. Microsoft (December 18, 2008). 2009年3月21日閲覧。
  8. ^ Windows® Internals: Including Windows Server 2008 and Windows Vista, Fifth Edition (PRO-Developer) ISBN 978-0-735-62530-3
  9. ^ Ollie Whitehouse (2007年2月). “An Analysis of Address Space Layout Randomization on Windows Vista” (PDF). 2010年7月24日閲覧。
  10. ^ WehnTrust
  11. ^ Security Architects' Ozone
  12. ^ Address-Space Randomization for Windows Systems
  13. ^ アドレス空間配置のランダム化 (ASLR)
  14. ^ Apple - Mac OS X - Security - Keeps safe from viruses and malware Archived 2011年5月25日, at the Wayback Machine.
  15. ^ Quick Leopard Update | securosis.com
  16. ^ Matasano Chargen » A Roundup Of Leopard Security Features
  17. ^ Matasano Chargen » What We’ve Since Learned About Leopard Security Features
  18. ^ TippingPoint | DVLabs | New Leopard Security Features - Part I: ASLR
  19. ^ Android Security”. Android Developers. 7 July 2012閲覧。

外部リンク