テオ・デ・ラート W^X (Write XOR Execute) メモリ保護メカニズムを強化する予定です。 このメカニズムの本質は、書き込みと実行のためにプロセス メモリ ページに同時にアクセスできないことです。 したがって、コードは書き込みが無効になった後にのみ実行でき、メモリ ページへの書き込みは実行が無効になった後にのみ可能になります。 W^X メカニズムは、スタック オーバーフローを含む一般的なバッファ オーバーフロー攻撃からユーザー空間アプリケーションを保護するのに役立ち、OpenBSD で有効です。 .
W^X の作業を開始したときから、JIT を使用するアプリケーションがかなりの数あったため、これが長い道のりであることは明らかでした。 JIT 実装は、次の XNUMX つのカテゴリに分類できます。
- メモリを W 状態と X 状態の間で切り替え、システム コールの「コスト」を受け入れる .
- 同じメモリの W マッピングと X マッピングのペアの間にエイリアスを作成します。
- 最も「ダーティ」なオプションには、同時記録と実行を可能にする W|X メモリ モデルが必要です。
現在、XNUMX 番目のオプションを使用するプログラムは大幅に減り、XNUMX 番目と XNUMX 番目のオプションを使用するプログラムが増えています。 ただし、W|X JIT (主に Chromium と Iridum) でプログラムを実行する必要があるため、「wxallowed」ファイルシステム マウント オプションが追加されました。これにより、実行可能ファイル ELF が存在する場合に、書き込みと実行の両方にメモリを同時に使用できるようになります。ファイルには「wxneeded」マーカーが付けられ、アプリケーション自体もメカニズムを使用してさらに保護されました и 使用するシステム コールのリストとアプリケーションで使用できるファイル システムの部分をそれぞれ制限します。
このようなアプリケーションの脆弱性の悪用をさらに複雑にするために、メカニズムへの追加が提案されています。 、システム コールが書き込み可能なメモリ ページから実行されているかどうかを確認します。 ページが書き込み可能な場合、プロセスは強制終了されます。 こうすることで、攻撃者はシステム コールを悪用できなくなり、JIT 実装内で必要なガジェットを見つけようとしたり、システム コール スタブを内部で直接検出するというより困難な作業を行うことさえ余儀なくされます。 .
Chrome/Iridium プロセスは、pledge と unveil を使用してすでに非常に確実に保護されていますが、たとえば write(2) システム コールを使用する機能を削除すると、攻撃者にとってさらなる困難が生じるため、明らかに何らかの利点があります。 ただし、JIT 実装で W|X メモリからのネイティブ システム コールを使用する場合にも問題が発生する可能性があります。 ただし、ABI は何度も変更されていますが、誰も問題を報告していないため、これが当てはまらないことを期待する理由があります。
変更は OpenBSD-Current ブランチの通常のスナップショットですでに利用可能になっており、興味のある方はぜひテストしてください。
Chrome/Iridium でのこのモードの登場に関する関連ニュースについては、Theo からの個別のコメントが必要です。 。 彼の観点からは、これは一部の使用モデルでは許容できますが、このモードではプロセッサの負荷が明らかに増加するため、おそらくすべてではありません。 現在、/usr/local の「wxallowed」を無効にすると Chrome はほとんど機能しますが、一部の拡張機能 (ゴーストなど) で問題が発生する可能性があります。 いずれにせよ、Theo は、近い将来、JITless モードでの本格的な作業が完全に動作する状態になることを望んでいます。
出所： オープンネット.ru