Log4j 2 ライブラリ (CVE-2021-45105) で別の脆弱性が確認されました。これは、前の 4 つの問題とは異なり、危険なものとして分類されていますが、重大ではありません。 この新しい問題により、サービス拒否が発生し、特定の行の処理時にループやクラッシュの形で現れます。 この脆弱性は、数時間前にリリースされた Log2.17j 8 リリースで修正されました。 この問題は Java XNUMX を搭載したシステムでのみ発生するため、この脆弱性の危険性は軽減されます。
この脆弱性は、ログ出力形式を決定するために ${ctx:var} などのコンテキスト クエリ (コンテキスト ルックアップ) を使用するシステムに影響します。 Log4j バージョン 2.0-alpha1 から 2.16.0 には、制御されない再帰に対する保護が欠けていたため、攻撃者が置換に使用される値を操作してループを引き起こし、スタック領域の枯渇とクラッシュを引き起こす可能性がありました。 特に「${${::-${::-$${::-j}}}}」などの値を代入する際に問題が発生していました。
さらに、Blumira の研究者が、外部ネットワーク リクエストを受け入れない脆弱な Java アプリケーションを攻撃するオプションを提案していることにも注目してください。たとえば、Java アプリケーションの開発者やユーザーのシステムがこの方法で攻撃される可能性があります。 この手法の本質は、ローカル ホストからのみネットワーク接続を受け入れるか、RMI リクエスト (リモート メソッド呼び出し、ポート 1099) を処理する脆弱な Java プロセスがユーザーのシステム上にある場合、実行される JavaScript コードによって攻撃が実行される可能性があるということです。ユーザーがブラウザで悪意のあるページを開いたとき。 このような攻撃中に Java アプリケーションのネットワーク ポートへの接続を確立するには、WebSocket API が使用されます。WebSocket API には、HTTP リクエストとは異なり、同一オリジン制限が適用されません (WebSocket は、ローカルのネットワーク ポートをスキャンするためにも使用できます)ホストを使用して利用可能なネットワーク ハンドラーを決定します)。
また、Google が公開した、Log4j の依存関係に関連するライブラリの脆弱性を評価した結果も興味深いです。 Google によると、この問題は Maven Central リポジトリ内の全パッケージの 8% に影響を及ぼします。 特に、直接および間接的な依存関係を通じて Log35863j に関連付けられた 4 個の Java パッケージが脆弱性にさらされました。 同時に、Log4j が直接の第 17 レベルの依存関係として使用されるのは 83% のケースのみであり、影響を受けるパッケージの 4% では、バインディングは Log21j に依存する中間パッケージを通じて実行されます。 12 番目以上のレベルの依存症 (14% - 26 番目のレベル、6% - 35863 番目のレベル、4620% - 13 番目のレベル、XNUMX% - XNUMX 番目のレベル、XNUMX% - XNUMX 番目のレベル)。 脆弱性の修正ペースにはまだ改善の余地が多く、脆弱性が特定されてから XNUMX 週間後、特定された XNUMX 個のパッケージのうち、これまでに問題が修正されたのは XNUMX 個のみです。 XNUMX%で。
一方、米国サイバーセキュリティ・インフラ保護庁は、連邦政府機関に対し、Log4j脆弱性の影響を受ける情報システムを特定し、問題をブロックするアップデートを23月28日までにインストールするよう求める緊急指令を出した。 23 月 XNUMX 日までに、組織はその取り組みについて報告する必要があります。 問題のあるシステムの特定を簡単にするために、脆弱性があることが確認された製品のリストが作成されました (リストには XNUMX を超えるアプリケーションが含まれています)。
出所： オープンネット.ru