Google Project Zero チームの研究者は、Linux カーネルの tty サブシステムの TIOCSPGRP ioctl ハンドラーの実装における脆弱性 (CVE-2020-29661) を悪用する方法を公開し、また、そのような攻撃をブロックする可能性のある保護メカニズムを詳細に調査しました。脆弱性。
この問題の原因となっていたバグは、昨年 3 月 5.9.13 日に Linux カーネルで修正されました。この問題はバージョン 2020 までのカーネルで発生しますが、ほとんどのディストリビューションは、昨年提供されたカーネル パッケージ (Debian、RHEL、SUSE、Ubuntu、Fedora、Arch) のアップデートで問題を修正しました。同様の脆弱性 (CVE-29660-XNUMX) が TIOCGSID ioctl 呼び出しの実装でも同時に見つかりましたが、これもすべての箇所ですでに修正されています。
この問題は、ロックを設定する際のエラーによって発生し、ioct 操作を通じてユーザー空間から悪用された use-after-free 条件を作成するために使用された drivers/tty/tty_jobctrl.c コードで競合状態が発生し、TIOCSPGRP を呼び出します。カーネル 10-4.19.0-amd13 を使用した Debian 64 での特権昇格に対して、有効なエクスプロイトが実証されています。
同時に、公開された記事では、有効なエクスプロイトを作成する手法ではなく、そのような脆弱性から保護するためにカーネルにどのようなツールが存在するかに焦点を当てています。この結論は快適なものではありません。ヒープ内のメモリのセグメント化や解放後のメモリ アクセスの制御などの方法は、パフォーマンスの低下につながるため実際には使用されていません。また、CFI (Control Flow Integrity) ベースの保護は、攻撃の後半段階でエクスプロイトをブロックするため、改善が必要です。
長期的に何が違いを生むかを考えると、目立つのは、高度な静的アナライザーの使用、またはチェックするための豊富な注釈 (Checked C など) を備えた Rust や C 言語などのメモリセーフ言語の使用です。ビルドフェーズ中の状態、ロック、オブジェクト、ポインター。保護方法には、panic_on_oops モードのアクティブ化、カーネル構造の読み取り専用モードへの切り替え、seccomp などのメカニズムを使用したシステム コールへのアクセスの制限も含まれます。
出所： オープンネット.ru