この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。（2020年5月）

Exec Shield はレッドハットが2002年後半に開始したプロジェクトであり、Linuxシステムに対するワームなどの自動化された攻撃の危険性を低減することを目的としている。最初の成果は、Linuxカーネル用セキュリティパッチであり、NXビットがハードウェアで実装されていないx86系マイクロプロセッサでNXビットをエミュレートするものだった。Exec Shield には他にも多数のコンポーネントがあるが、この最初のパッチだけを Exec Shield と呼ぶ人もいる。

概要

この最初のExec Shieldパッチは、データ用メモリページを実行不可能とし、コード用メモリページを書き込み不能とする。これはバッファオーバーランなどの技法を使ってデータの中にコードを挿入するなどの試みを抑止する。Exec Shieldには他に mmap() とヒープのベースアドレスのASLR (Address Space Layout Randomization) も行う。

このパッチは他にシェルコードの挿入と実行をより困難にする効果もある。Exec Shield を利用するにあたって、アプリケーションの再コンパイルは不要だが、一部のアプリケーション (Mono, Wine, XEmacs) は動作が若干変わってしまう。

Exec Shieldプロジェクトから生まれた他の機能としては、いわゆるPosition Independent Executables (PIE) というLinuxカーネル用ASLRパッチ、glibc内部の広範囲なセキュリティチェック、GCC Fortify Source機能、GCCスタックプロテクタの移植とマージなどがある。

実装

Exec Shieldは、x86CPUのコードセグメント境界を利用して動作する。そのため非常に軽量であるが、任意の仮想記憶配置を完全に保護するわけではない。mprotect() で実行可能な範囲を広げると、その範囲内の保護は無効になる。Ingo Molnar は電子メールでの会話でこの点を指摘している。幸いにもほとんどのアプリケーションはその点で問題ない。特に重要なスタックは、アプリケーションが明示的に指定しない限り実行可能にはならない。

2004年8月現在、Exec Shieldプロジェクトの成果物は mprotect() を制限するわけではない。もっとも、初期状態で実行不可能なメモリであっても後から実行可能にすることはできるので、カーネルがアプリケーションに対してメモリページを同時に書き込み可能かつ実行可能にすることがある。しかし、SELinuxと併用することで Fedora Core ディストリビューションの標準ポリシーでは、互換性を理由とした一部の例外を除いて、ほとんどの実行ファイルのそのような動作を禁止している。

歴史

Exec Shield はレッドハットの様々な人々が開発に関わった。最初のパッチを2003年5月にリリースしたのはレッドハットの Ingo Molnar であった。これは Fedora Core 1から6とRed Hat Enterprise Linux 3 (update 3) から4に採用された^[1][2]。他に関与した人々としては、Jakub Jelínek、Ulrich Drepper、Richard Henderson、Arjan van de Ven らがいる。

関連項目

• NXビット
• PaX

脚注

外部リンク

• Ingo Molnar's Exec Shield patch web page
• Newsforge Feature Article
• Red Hat Magazine Feature/Project Article
• ExecShieldの問題点