実行可能スペースの保護

コンピュータ セキュリティでは、実行可能空間保護はメモリ領域を実行不可としてマークし、これらの領域でマシン コードを実行しようとすると例外が発生します。これは、 NX ビット(非実行ビット)などのハードウェア機能、または場合によってはそれらの機能のソフトウェア エミュレーションを利用します。ただし、NX ビットをエミュレートまたは提供するテクノロジは通常、測定可能なオーバーヘッドを課しますが、ハードウェアが提供する NX ビットを使用する場合は測定可能なオーバーヘッドは課されません。

Burroughs 5000 は、1961 年の発表時に実行可能空間保護のハードウェア サポートを提供しました。この機能は、少なくとも 2006 年まで後継機に残っていました。タグ付きアーキテクチャの実装では、メモリの各ワードに、コードまたはデータを指定する隠しタグ ビットが関連付けられていました。そのため、ユーザー プログラムはプログラム ワードの書き込みや読み取りさえできず、データ ワードを実行することもできません。

オペレーティング システムがメモリの書き込み可能な領域の一部またはすべてを非実行可能としてマークできる場合、スタックおよびヒープメモリ領域が実行可能になるのを防ぐことができます。これにより、 Sasser ワームやBlasterワームなど、特にコードを挿入して実行するバッファ オーバーフロー 攻撃の成功を防ぐことができます。これらの攻撃は、メモリの一部 (通常はスタック) が書き込み可能かつ実行可能であることに依存しており、そうでない場合は攻撃は失敗します。

多くのオペレーティング システムでは、実行可能スペース保護ポリシーが実装されているか、または利用可能です。以下に、そのようなシステムの一覧をアルファベット順に示します。各システムでは、テクノロジが最新のものから古いものの順に並べられています。

一部のテクノロジについては、各テクノロジがサポートする主な機能の概要が示されています。概要は以下のように構成されています。

• ハードウェアでサポートされているプロセッサ: (CPU アーキテクチャのコンマ区切りリスト)
• エミュレーション: (いいえ) または (アーキテクチャ非依存) または (CPU アーキテクチャのコンマ区切りリスト)
• その他のサポート: (なし) または (CPU アーキテクチャのコンマ区切りリスト)
• 標準配布: (いいえ) または (はい) または (技術をサポートする配布またはバージョンのコンマ区切りリスト)
• 発売日: (初回リリース日)

アーキテクチャに依存しないエミュレーションを提供するテクノロジは、ハードウェアでサポートされていないすべてのプロセッサで機能します。「その他のサポート」行は、明示的な NX ビットが存在しないが、ハードウェアによって何らかの方法でエミュレートできる、グレー エリア メソッドを許可するプロセッサ用です。

Android 2.3以降では、これをサポートするアーキテクチャには、非実行可能スタックとヒープを含む非実行可能ページがデフォルトで存在します。^{[1] [2] [3]}

NX ビットの初期サポートは、それをサポートするx86-64およびIA-32プロセッサ上で、 2004 年 6 月 8 日にFreeBSD -CURRENT で初めて導入されました。これは、5.3 リリース以降の FreeBSD リリースに含まれています。

Linuxカーネルは、AMD、Intel、Transmeta、VIA 製の最新の 64 ビット プロセッサなど、それをサポートするx86-64およびIA-32プロセッサで NX ビットをサポートしています。x86-64 CPU の 64 ビット モードでのこの機能のサポートは、2004 年に Andi Kleen によって追加され、同年後半にIngo Molnárによって 64 ビット CPU の 32 ビット モードでのサポートが追加されました。これらの機能は、2004 年 8 月にカーネル バージョン 2.6.8 がリリースされて以来、Linux カーネルのメインラインの一部となっています。^[4]

32 ビット x86 カーネルは、通常、AMD64 または IA-64 が提供する NX ビットを期待しないため、32 ビット x86 CPU と 64 ビット IA-32 互換 CPU の両方で実行できる 32 ビット x86 カーネルで NX ビットが利用可能であることは重要です。NXイネーブラパッチは、これらのカーネルが NX ビットが存在する場合はそれを使用することを保証します。

Fedora、Ubuntu、openSUSEなどの一部のデスクトップLinux ディストリビューションでは、32 ビット モードで NX ビットにアクセスするために必要な HIGHMEM64 オプションが、デフォルトのカーネルでデフォルトで有効になっていません。これは、NX ビットを使用するために必要なPAEモードが、NX をサポートしていないPentium Pro以前(Pentium MMX を含む) およびCeleron MとPentium Mプロセッサでブート エラーを引き起こすためです。PAE をサポートしないその他のプロセッサは、 AMD K6以前、Transmeta Crusoe、VIA C3以前、およびGeode GX と LX です。VMware Workstation の4.0 より前のバージョン、Parallels Workstation の4.0 より前のバージョン、およびMicrosoft Virtual PCとVirtual Server は、ゲスト上で PAE をサポートしません。Fedora Core 6 と Ubuntu 9.10 以降では、PAE と NX をサポートするカーネル PAE パッケージが提供されています。

NX メモリ保護は、それをサポートするハードウェアを持ち、64 ビット カーネルまたは 32 ビット サーバー カーネルを実行するすべてのシステムで、Ubuntu で常に利用可能でした。Ubuntu 9.10 以降の 32 ビット PAE デスクトップ カーネル (linux-image-generic-pae) は、NX CPU 機能を備えたハードウェアに必要な PAE モードも提供します。NX ハードウェアがないシステムの場合、32 ビット カーネルはソフトウェア エミュレーションを介して NX CPU 機能の近似値を提供するようになり、攻撃者がスタックまたはヒープ メモリから実行する可能性のある多くのエクスプロイトをブロックするのに役立ちます。

非実行機能は、多くのリリースでこの機能をサポートする他の非 x86 プロセッサにも存在しています。

Red Hatカーネル開発者のIngo Molnár は、32 ビットx86 CPUで NX 機能を近似して利用するためのLinux カーネル パッチExec Shieldをリリースしました。Exec Shield パッチは 2003 年 5 月 2 日にLinux カーネル メーリング リストにリリースされましたが、エミュレーションの複雑な部分を処理するためにコア コードにいくつかの侵入的な変更が伴うため、ベース カーネルとのマージは拒否されました。Exec Shield のレガシー CPU サポートは、コード セグメントの上限を追跡することで NX エミュレーションを近似します。これにより、コンテキスト スイッチ中に数サイクルのオーバーヘッドが発生しますが、これは事実上測定不可能です。NX ビットのないレガシー CPU の場合、Exec Shield はコード セグメントの上限以下のページを保護できません。スタックなどの上位メモリを実行可能としてマークする mprotect() 呼び出しは、その上限以下のすべてのメモリも実行可能としてマークします。したがって、これらの状況では、Exec Shield のスキームは失敗します。これが、Exec Shield の低いオーバーヘッドの代償です。 Exec Shield は、スタックまたはヒープが実行可能である必要があるかどうかを決定する 2 つのELFヘッダー マーキングをチェックします。これらはそれぞれ PT_GNU_STACK と PT_GNU_HEAP と呼ばれます。Exec Shield では、バイナリ実行可能ファイルとライブラリの両方にこれらの制御を設定できます。実行可能ファイルが、特定の制限を緩和する必要があるライブラリをロードする場合、実行可能ファイルはそのマーキングを継承し、その制限を緩和します。

• ハードウェア対応プロセッサ: LinuxがサポートするすべてのNX
• エミュレーション: IA-32 ( x86 ) および互換のコードセグメント制限を使用したNX近似
• その他サポート: なし
• 標準ディストリビューション: Fedora CoreおよびRed Hat Enterprise Linux
• 発売日: 2003年5月2日

PaX NX テクノロジーは、NX 機能をエミュレートしたり、ハードウェア NX ビットを使用したりすることができます。PaX は、32 ビット x86 などの NX ビットを持たない x86 CPU で動作します。Linuxカーネルにはまだ PaX が同梱されていません (2007 年 5 月現在)。パッチは手動でマージする必要があります。

PaX は、SEGMEXEC と PAGEEXEC という 2 つの NX ビット エミュレーション方法を提供します。SEGMEXEC 方法では、実行とデータ アクセスを分離するために使用される仮想メモリ ミラーリングによって発生する一定のスカラー値である、測定可能で低いオーバーヘッド (通常 1% 未満) が発生します。^[5] SEGMEXEC には、タスクの仮想アドレス空間を半分にする効果もあり、タスクが通常よりも少ないメモリにアクセスできます。タスクが通常のアドレス空間の半分以上にアクセスする必要がある場合を除き、これは問題にはなりませんが、これはまれです。SEGMEXEC によってプログラムが使用するシステム メモリ (RAM など) が増えることはありません。アクセスできる量を制限するだけです。32 ビット CPU では、これは 3 GB ではなく 1.5 GB になります。

PaX は、高速化のために PAGEEXEC で Exec Shield の近似に似た方法を提供しますが、上位メモリが実行可能としてマークされると、この方法は保護を失います。このような場合、PaX は PAGEEXEC で使用される古い可変オーバーヘッド方法にフォールバックして、CS 制限以下のページを保護します。これは、特定のメモリ アクセス パターンでは非常にオーバーヘッドの高い操作になる可能性があります。ハードウェア NX ビットを提供する CPU で PAGEEXEC 方法を使用すると、ハードウェア NX ビットが使用されるため、大きなオーバーヘッドは発生しません。

PaX は、プログラムがメモリをマークして、潜在的な悪用に役立つメモリを生成するのを防ぐための mprotect() 制限を提供します。このポリシーにより、特定のアプリケーションが機能しなくなりますが、影響を受けるプログラムに対しては無効にすることができます。

PaX では、バイナリ実行ファイルごとに次のテクノロジ機能を個別に制御できます。

• ページEXEC
• SEGMEXEC
• mprotect() の制限
• トランポリンエミュレーション
• ランダム化された実行可能ベース
• ランダム化された mmap() ベース

PaX は PT_GNU_STACK と PT_GNU_HEAP の両方を無視します。以前は、PaX にはこれらの設定を尊重する構成オプションがありましたが、そのオプションはセキュリティ上の理由から、役に立たないと見なされて削除されました。通常、プログラムはロード時にスタックを mprotect() するため、mprotect() 制限を無効にすると、PT_GNU_STACK と同じ結果が得られます。これは常に当てはまるとは限りません。これが失敗する状況では、PAGEEXEC と SEGMEXEC の両方を無効にするだけで、すべての実行可能スペース制限が効果的に削除され、タスクの実行可能スペースに対する保護が非 PaX システムと同じになります。

• ハードウェアでサポートされるプロセッサ: Alpha、AMD64、IA-64、MIPS (32 および 64 ビット)、PA-RISC、PowerPC、SPARC
• エミュレーション: IA-32 ( x86 )
• その他サポート対象: PowerPC (32 ビットおよび 64 ビット)、SPARC (32 ビットおよび 64 ビット)
• 標準ディストリビューション: Alpine Linux
• 発売日: 2000年10月1日

Intel 版macOS は、Apple がサポートするすべての CPU で NX ビットをサポートします (最初の Intel リリースである Mac OS X 10.4.4 以降)。Mac OS X 10.4 では、NX スタック保護のみがサポートされていました。Mac OS X 10.5 では、すべての 64 ビット実行可能ファイルに NX スタックとヒープ、W^X 保護が組み込まれています。これには、x86-64 (Core 2 以降) とG5 Macの64 ビットPowerPCが含まれます。

NetBSD 2.0以降（2004年12月9日）では、これをサポートするアーキテクチャには非実行スタックとヒープがあります。^[6]

ページ単位の粒度を持つアーキテクチャは、 alpha、amd64、hppa、i386 ( PAE付き)、powerpc (ibm4xx)、sh5、sparc ( sun4m、sun4d )、sparc64です。

これらをリージョン粒度でのみサポートできるアーキテクチャは、i386 (PAE なし)、その他の powerpc (macppc など) です。

他のアーキテクチャーでは、非実行可能スタックやヒープのメリットは得られません。NetBSD は、デフォルトでは、それらのアーキテクチャーでこれらの機能を提供するためにソフトウェア エミュレーションを使用しません。

OpenBSD オペレーティング システムの W^X と呼ばれるテクノロジは、書き込み可能なページを、それをサポートするプロセッサ上でデフォルトで非実行可能としてマークします。32 ビットx86プロセッサでは、コード セグメントは、アドレス空間の一部のみを含むように設定され、実行可能空間の保護をある程度提供します。

OpenBSD 3.3 は 2003 年 5 月 1 日にリリースされ、W^X を組み込んだ最初のバージョンでした。

• ハードウェア対応プロセッサ: Alpha、AMD64、HPPA、SPARC
• エミュレーション: IA-32 (x86)
• その他サポート: なし
• 標準配布: はい
• 発売日: 2003年5月1日

Solaris は、Solaris 2.6 (1997) 以降、SPARC プロセッサ上でスタック実行をグローバルに無効化する機能をサポートしてきました。Solaris 9 (2002) では、実行可能ファイルごとにスタック実行を無効にする機能が追加されました。

Windows（NT 4.0、2000、XP）用の非実行スタックの最初の実装は、2001年にSecureWaveのSecureStack製品を通じて、PaX ^{[7] [8]の成果に基づいて公開されました。}

Windows XP Service Pack 2 (2004) およびWindows Server 2003 Service Pack 1 (2005)以降、NX 機能がx86アーキテクチャに初めて実装されました。Windows 上の実行可能領域の保護は、「データ実行防止」(DEP) と呼ばれます。

Windows XP または Server 2003 では、NX 保護はデフォルトで重要なWindows サービスにのみ使用されていました。x86プロセッサがハードウェアでこの機能をサポートしていた場合、Windows XP/Server 2003 では NX 機能がデフォルトで自動的にオンになっていました。x86 プロセッサでこの機能がサポートされていなかった場合、保護は提供されませんでした。

DEP の初期の実装では、アドレス空間レイアウトのランダム化(ASLR) が提供されていなかったため、攻撃中に DEP を無効にするために使用できる可能性のあるreturn-to-libc 攻撃が可能でした。 ^[9] PaXのドキュメントでは、ASLR が必要な理由が詳しく説明されています。 ^[10] ASLR がない場合でも DEP を回避できる方法を詳しく説明した概念実証が作成されました。^{[11]破損した画像や}MP3などの準備されたデータのアドレスが攻撃者に知られると、 攻撃を成功させる可能性があります。

Microsoft は、 Windows VistaおよびWindows Server 2008に ASLR 機能を追加しました。このプラットフォームでは、 32 ビット Windows でのPAE カーネルの自動使用と 64 ビット カーネルでのネイティブ サポートを通じて DEP が実装されています。Windows Vista DEP は、メモリの特定の部分をデータのみを保持するものとしてマークし、NX または XD ビット対応プロセッサがそれを非実行可能として認識することによって機能します。^{[12] Windows では、バージョン Vista 以降、特定のプロセスに対して DEP が有効になっているか無効になっているかは}、Windows タスク マネージャーのプロセス/詳細タブで確認できます。

Windows は、Microsoft の「安全な構造化例外処理」(SafeSEH) を通じてソフトウェア DEP ( NX ビットを使用せずに) を実装しています。適切にコンパイルされたアプリケーションの場合、SafeSEH は、プログラム実行中に例外が発生した場合、その例外のハンドラーがアプリケーションによって最初にコンパイルされたときに定義されたものであるかどうかをチェックします。この保護の効果は、攻撃者がチェックされていないプログラム入力を通じてデータ ページに格納した独自の例外ハンドラーを追加できないことです。^{[12] [13]}

NX がサポートされている場合、デフォルトで有効になっています。Windows では、プログラムがAPIおよびPE ファイルのセクション ヘッダーを通じて、どのページが実行を許可しないかを制御できます。API では、 Win32 API 呼び出しVirtualAlloc[Ex]およびVirtualProtect[Ex]を通じて、NX ビットへの実行時アクセスが公開されます。各ページは、実行可能または実行不可として個別にフラグ付けできます。以前の x86 ハードウェア サポートがなかったにもかかわらず、実行可能ページと実行不可ページの両方の設定が最初から提供されていました。NX 以前の CPU では、「実行可能」属性の存在は効果がありません。これは機能するかのように文書化されていたため、ほとんどのプログラマーが適切に使用していました。PE ファイル形式では、各セクションで実行可能性を指定できます。実行フラグは形式の初期から存在しており、標準リンカーはNX ビットよりずっと前から、常にこのフラグを正しく使用してきました。このため、Windows は古いプログラムに NX ビットを適用できます。プログラマーが「ベスト プラクティス」に従っていると仮定すると、NX が実際に適用されるようになったため、アプリケーションは正常に動作するはずです。問題が発生したのはごく少数のケースのみです。Microsoft 独自の .NET ランタイムは NX ビットに問題があったため更新されました。

• ハードウェア サポートされるプロセッサ: x86-64 (AMD64 および Intel 64)、IA-64、Efficeon、Pentium M (以降のリビジョン)、AMD Sempron (以降のリビジョン)
• エミュレーション: はい
• その他サポート: なし
• 標準配布: Windows XP以降
• 発売日: 2004年8月6日

Microsoft のXboxでは、CPU に NX ビットはありませんが、XDKの新しいバージョンでは、コード セグメントの制限がカーネルの.dataセクションの先頭に設定されています (通常の状況では、このポイントより後にコードがあってはなりません)。バージョン 51xx 以降、この変更は新しい Xbox のカーネルにも実装されました。これにより、終了して常駐するプログラムになるために使用されていた古いエクスプロイトの手法が破られました。ただし、Xbox カーネルの基本的な脆弱性は影響を受けなかったため、この新しいカーネル バージョンをサポートする新しいエクスプロイトがすぐにリリースされました。

コードが実行時に記述され実行される場合（JITコンパイラが代表的な例です）、コンパイラは実行フラグが立てられておりトラップされないエクスプロイトコード（ JIT Sprayなど）を生成するために使用される可能性があります。 ^{[14] [15]}

リターン指向プログラミングでは、実行可能スペース保護が実施されている場合でも、攻撃者が任意のコードを実行できる可能性があります。

• バッファオーバーフロー
• バッファオーバーフロー保護
• ヒープオーバーフロー
• スタック破壊保護
• 制御されていない書式文字列