数日前、研究チームが次のようなニュースを発表しました。 Qualys がサービス拒否の脆弱性を発見 systemd のスタック枯渇が原因であるため、権限のないユーザーがこの脆弱性を悪用できる可能性があります。 systemdをブロックします。
脆弱性 すでに (CVE-2021-33910) としてカタログ化されています systemd に影響を与えるのは、FUSE 経由で 8 MB を超えるパス サイズのディレクトリをマウントしようとしたときの失敗と、コントロールの初期化プロセス (PID1) がヒープ メモリを使い果たし、クラッシュすることが原因であることが記載されています。システムは「パニック」状態にあります。
この脆弱性は、commit 220c（「カーネル：ユニット名の操作と検証ロジックのリワーク」）によってsystemd v2015（7410616年XNUMX月）に導入されました。これにより、ヒープのstrdup（）がバッテリーのstrdupa（）に置き換えられました。 この脆弱性の悪用に成功すると、特権のないユーザーがカーネルパニックを介してサービス拒否を引き起こす可能性があります。
Qualys の研究チームが脆弱性を確認するとすぐに、Qualys は責任ある脆弱性の開示に参加し、作成者およびオープン ソース ディストリビューションと調整して脆弱性を発表しました。
研究者たちは次のように述べています 問題 CVE-2021-33910 に関連する問題は、次の事実により発生します。 systemd は /proc/self/mountinfo の内容を監視および解析します そして、unit_name_path_escape() 関数の各マウント ポイントを処理します。これにより、ヒープではなくスタックにデータを割り当てる処理を行う「strdupa()」と呼ばれる操作が実行されます。
それが理由です 許可される最大スタック サイズには制限があります 「RLIMIT_STACK」機能により、 マウント ポイントへのパスが長すぎるとプロセス「PID1」がクラッシュする システムの停止につながります。
さらに、攻撃を機能させるためには、パス サイズが 8 MB を超える高度にネストされたディレクトリをマウント ポイントとして使用するとともに、より単純な FUSE モジュールを使用できるとも述べています。
また Qualys の研究者が次のことを行っていることに言及することが重要です。 特定のケースに言及する 脆弱性があるため、 特に systemd バージョン 248 では、エクスプロイトは機能しません systemd コードにバグが存在し、/proc/self/mountinfo が失敗するためです。 また、非常に似た状況が 2018 年に発生したことも興味深いことです。Qualys の研究者は、Linux カーネルの CVE-2018-14634 脆弱性のエクスプロイトを作成しようとしていたときに、systemd に他の XNUMX つの重大な脆弱性を発見しました。
脆弱性について Red Hat チームが言及した RHEL をサポートする製品も影響を受ける可能性があります。
これには以下が含まれます：
- RHEL または UBI コンテナー イメージに基づく製品コンテナー。 これらのイメージは定期的に更新され、この欠陥に対する修正が利用可能かどうかを示すコンテナのステータスは、Red Hat Container Catalog (https://access.redhat.com/containers) の一部である Container Health Index で確認できます。 。
- RHEL チャネルからパッケージをプルする製品。 これらの製品環境では、基盤となる Red Hat Enterprise Linux systemd パッケージが最新であることを確認してください。
この脆弱性の攻撃範囲は広いため、, Qualys は、ユーザーが対応するパッチを適用することを推奨します。 (すでに数日前にリリースされています) この脆弱性に対して直ちに対応してください。
すでに述べたように、この問題は systemd 220 (2015 年 XNUMX 月) 以降に発生しており、 すでに修正されています のメインリポジトリ systemd であり、ほとんどのディストリビューションで修正されています 主要な Linux とその派生製品のステータスは、次のリンク (Debianの, Ubuntu, フェドーラ, RHEL、SUSE、 アーチ).
最後に、 あなたがそれについてもっと知りたいなら この脆弱性については、詳細を確認できます 次のリンクで。