セキュリティ研究者のAlvaro Muñoz氏は最近、Apache Commons Textバージョン1.5から1.9に存在する重大な脆弱性について警告した。この脆弱性は「Text4Shell」と呼ばれ、CVE-2022-42889として特定されており、StringSubstitutor APIを介したリモートコード実行を可能にする。これを受け、スクリプトの補間をデフォルトで無効にしたバージョン1.10がリリースされた。
深刻度評価が9.8と非常に高く、その名前から恐れられたLog4Shellの脆弱性との類似性が示唆される一方、Rapid7の研究者Erick Galinkin氏は不公平な比較だと指摘した。「この脆弱性の性質上、Log4Shellとは異なり、アプリケーションがCommons Textの脆弱なコンポーネントを使って、信頼できない、潜在的に悪意のある入力を処理するケースはまれでしょう」と同氏は記している。
WordPressセキュリティ企業のWordfenceは、悪意ある攻撃者が脆弱なインストールをスキャンしていることを検知したが、同社もText4ShellのリスクはLog4jよりはるかに低いと認めている。「Apache Commons Textライブラリは安全でない形で使われることがはるかに少なく、攻撃が成功する可能性も大幅に低い」
Text4Shellへの対応
Endor LabsのCEO兼共同創業者であるVarun Badhwar氏は、この脆弱性は懸念されるものの、驚くべきことではないと述べた。「開発者がコード開発中にミスをするのは自然なことであり、予想されることでもあります。特に、これを本業としていないオープンソースのメンテナーやコントリビューターについてはなおさらです」と同氏は述べている。
Badhwar氏によると、Text4Shellが多くの企業にもたらす最大の問題は、この問題の調査と修正に必要な時間だという。「何よりもまず、ほとんどの組織には、この依存関係がどこで使われているかを迅速に発見するためのツールがありません」と同氏は述べた。
少なくともこの点では、Badhwar氏はLog4Shellとの比較は適切だと述べている。米国サイバー安全審査委員会によるLog4Shellに関する最新の報告書［PDF］では、米国政府の閣僚級省庁の1つが、この脆弱性の調査と対応に33,000時間を費やしたと記されている。
「メンテナーには最善を期待したいところですが、オープンソースソフトウェアのエンドユーザーは、適切な依存関係を選択し、効率的に安全を確保し、こうしたインシデントを高度な自動化によって迅速に調査・対応できるようにする依存関係ライフサイクル管理ソリューションに投資する必要があります」とBadhwar氏は付け加えた。
次を参照：主要なコードデバッグおよびコードセキュリティツール
依存関係の依存関係
Endor Labsのセキュリティ研究者Henrik Plate氏はeSecurity Planetに対し、影響を受ける依存関係が見えにくいことが最大の課題だと語った。「オープンソースコンポーネントの脆弱性に関する一般的な問題は、その大半がソフトウェア開発者が直接使うコンポーネント（依存関係）に影響しないことです」と同氏は述べた。「むしろ、そうした脆弱性は開発者が使う依存関係の依存関係に影響するため、特定のソフトウェアにとって、ある脆弱性が本当に重要なのかを開発者が判断するのは非常に困難になります」
Plate氏によると、Log4Shellの場合、脅威の中心にあるのはLog4jの普及度であり、「文字通り、どこにでも見つかる」からだという。
さらに、脆弱性はインターネットに直接公開されていないシステムにも影響を及ぼす可能性がある。「脆弱性を引き起こす悪意ある文字列やテキストが、攻撃者によってあるシステムに投入され、その後さまざまなデータベースやシステムを経由して移動し、組織のネットワークの奥深くにある脆弱なシステムを悪用する可能性があります」と同氏は述べた。
「Log4jは、広範囲に及ぶ脆弱性への対応に伴うオーバーヘッドが、脆弱性そのものよりも危険になることが多いという事実を浮き彫りにしました」とPlate氏は付け加えた。
関連記事：ソフトウェアサプライチェーン：依存関係にとって危険な時代
攻撃対象領域の管理
Badhwar氏は最近のブログ記事で、平均的な企業では、開発者が直接ダウンロードするオープンソースの依存関係が40,000以上あり、依存関係1つにつき平均77個の依存関係がさらに取り込まれると指摘した。「これは大規模で制御不能な拡散を引き起こし、攻撃対象領域を拡大する一方で開発を遅らせます」と同氏は記している。
そのうえ、セキュリティチームは、そのコードがどこでどのように使われているかをほとんど把握できていないことが多い。そのため、脆弱性が公開された際に自社が影響を受けているかどうかを判断するのは、干し草の山から針を探すようなものになりかねない。
Plate氏によると、こうした問題への対応における同社の手法は、比較的独自性が高いという。「Endor Labsの特徴は、静的コード解析を実施し、あるオープンソースコンポーネントに含まれる脆弱なコード部分が、対象ソフトウェアのコンテキストで実行され得るかどうかを確認する点にあります。脆弱なコンポーネントが依存関係の山のどれほど深くに隠れていても関係ありません」と同氏は述べた。
「このコンテキスト情報は、毎週開示される数十件の脆弱性に優先順位を付けるうえで重要です。それらは何百、何千ものアラートを生みますが、その多くはそもそも開発者に知らせるべきではありません」とPlate氏は付け加えた。
さらに読む：