W^X（write xor execute、発音はW xor X ）は、オペレーティングシステムおよびソフトウェアフレームワークにおけるセキュリティポリシーです。これは、すべてのメモリページ（プログラムの仮想アドレス空間（プログラムが使用するメモリレイアウト）内の固定サイズのブロック）が書き込み可能または実行可能のいずれかであり、両方ではないことを保証することで、実行空間保護を実装します。このような保護がないと、プログラムはデータ用のメモリ領域にCPU命令を書き込み（データ「W」として）、その後、それらの命令を実行（実行可能「X」として、または読み取り実行「RX」として）することができます。メモリ書き込み者が悪意を持っている場合、これは危険です。
この用語は2003年にUnix系システム向けに初めて導入されましたが、現在では一部のマルチプラットフォームシステム（ .NET [ 1 ]など）でも使用されています。他のオペレーティングシステムでも、異なる名称で同様のポリシーが採用されています（例： WindowsのDEP）。
Unixでは、W^Xは通常、mprotectシステムコールを介して制御されます。SPARC 、x86-64、PA-RISC、Alpha、ARMなど、きめ細かなページ権限をサポートするプロセッサアーキテクチャでは、比較的シンプルです。
W^Xという用語は、ファイル システムの書き込み/実行権限にも適用され、ファイル書き込みの脆弱性 (メモリ内の場合など) と攻撃者の持続性を軽減します。[ 2 ]ファイル権限の制限を強制すると、メモリ マップされたファイルによって生じる W^X 強制のギャップを埋めることもできます。[ 3 ] [ 4 ]任意のネイティブ コードの使用を完全に禁止すると、コンピューター上の既存のコードでは露出されないカーネルと CPU の脆弱性を軽減することもできます。[ 5 ]より侵入性の低いアプローチは、実行可能メモリへのマッピング中はファイルをロックすることであり、これは事後検査のバイパスを防ぐのに十分です。
互換性
初期のIntel 64プロセッサの中には、W^Xに必要なNXビットを備えていないものもあったが、これは後のチップで登場した。Intel i386の ようなより制限の厳しいプロセッサでは、W^XはCSコードセグメントの制限を「一線」として用いる必要がある。これは、アドレス空間において、これを超えると実行が許可されずデータが配置される点であり、これを超えると実行が許可され、実行ページが配置される点である。この方式はExec Shieldで用いられた。[ 6 ]
リンカーの変更は、一般的にデータとコードを分離するために必要となる（リンカーやライブラリのランタイム関数に必要なトランポリンなど）。混合を許可するスイッチは、通常、Unix系システムで呼び出される[ 7 ]。execstack
W^X は、ジャストインタイムコンパイルにとっても小さな問題となる可能性があります。ジャストインタイムコンパイルでは、インタープリタがマシンコードをオンザフライで生成して実行します。歴史的にはFirefoxVirtualProtectも含め、ほとんどのシステムで使用されている単純な解決策は、 Windows またはUnix 系オペレーティングシステムでを使用して、インタープリタがマシンコードの書き込みを終えた後にページを実行可能にすることですmprotect。もう 1 つの解決策は、同じメモリ領域を 2 つのページにマッピングし、1 つは RW、もう 1 つは RX を使用することです。[ 8 ]どちらの解決策がより安全であるかについては、単純なコンセンサスはありません。後者のアプローチの支持者は、書き込み可能であったページの実行を許可することは W^X の目的にそぐわないと考えており (と呼ばれるこのような操作を制御するSELinuxポリシーが存在しますallow_execmod)、アドレス空間レイアウトのランダム化によって、両方のページを同じプロセスに配置しても安全になると考えています。前者のアプローチの支持者は、後者のアプローチは、2 つのページが 2 つの別々のプロセスに渡される場合にのみ安全であり、を呼び出すよりもプロセス間通信のコストが高くなると考えていますmprotect。
歴史
W^Xは、2003年5月にリリースされたOpenBSD 3.3で初めて実装されました。2004年には、MicrosoftがWindows XPにDEP（データ実行防止）と呼ばれる同様の機能を導入しました。LinuxのPaXおよびExec Shieldパッチ、NetBSDのPaX実装など、他のオペレーティングシステムでも同様の機能が利用可能です。Red Hat Enterprise Linux（およびCentOS）バージョン5、またはLinuxカーネル2.6.18-8では、SELinuxは、無効時にW^Xを提供する 、、、およびポリシーを受け取りました。allow_execmemallow_execheapallow_execmod
W^X（またはDEP）は、その存在のほとんどにおいてユーザーランドプログラムのみを保護してきましたが、2012年にマイクロソフトはこれをx86およびARMアーキテクチャ上のWindowsカーネルに拡張しました。[ 9 ] 2014年後半から2015年初頭にかけて、W^XはAMD64アーキテクチャ上のOpenBSDカーネルに追加されました。[ 10 ] 2016年初頭には、W^XはNetBSDのAMD64カーネルに完全に実装され、i386カーネルにも部分的に実装されました。
Apple Siliconプロセッサを搭載したmacOSコンピュータは、すべてのプログラムにW^Xを適用します。IntelベースのMacでは、OSのHardened Runtimeモードを使用するプログラムにのみこのポリシーが適用されます。[ 11 ] [ 12 ]
2016年のFirefox 46から2023年のFirefox 116まで、FirefoxのJavaScript仮想マシンはW^Xポリシーを実装しました。[ 8 ]これは後にパフォーマンス上の理由から一部のプラットフォームではロールバックされましたが、すべてのプログラムにW^Xを強制する他のプラットフォームでは残りました。[ 13 ]
.NETは2021年の.NET 6.0からW^Xを使用します。[ 1 ]
参考文献
- ^ a b「.NET 6 の新機能」 . docs.microsoft.com . Microsoft . 2021年11月9日閲覧。
- ^ 「API > 28 に対して execve() 制限を適用する」。
- ^ 「Zackのカーネルニュース」。
- ^ 「SARA 新しいスタック LSM」。
- ^ 「Linux カーネルの強化 (シリーズ 2.0.x)」。
- ^ "i386 W^X" . 2003年4月17日. 2014年6月19日閲覧。
- ^ – ManKier.com のLinuxシステム管理マニュアル。
- ^ a b「FirefoxでW^X JITコードが有効化」2016年4月29日閲覧。
- ^ 「Win8 でのエクスプロイト緩和の改善」。
- ^ 「AMD64 カーネルの W^X 保護」。
- ^ 「Apple SiliconへのJust-In-Timeコンパイラの移植」 developer.apple.com 。2022年4月17日閲覧。
- ^ 「ARM Macs FAQ」 . SecureMac. 2020年7月17日. 2022年4月17日閲覧。
- ^ "1835876 - コンテンツプロセスにおけるコードメモリ保護の無効化を検討してください" . bugzilla.mozilla.org . Mozilla . 2024年7月1日閲覧。