ほとんどの読者は、12月9日に公開されて以来、システム管理者の悩みを増やし続けているLog4jの脆弱性について、最近何かを学んだかもしれません。この脆弱性は悪用が比較的容易で、リモート・コード実行に利用でき、インターネット上のサーバに散在しています。近年公開された脆弱性の中でも最悪の部類に入ると言っても過言ではありません。ある意味で、Log4jから学んだ教訓は、目新しいものではありませんが、脆弱性は、自由ソフトウェアのエコシステムにおける問題のいくつかを、さらに明確に浮き彫りにしています。
何が悪かったのですか？
このバグの仕組みとそれを悪用する方法を詳述する多くの記事があり、この います。要するに、 、Apache Software Foundationによって商標登録され、配布されているJavaロギングパッケージで、多くの他のプロジェクトに含まれています。実際、この よると、Log4j は 2800 万回以上ダウンロードされ、ほぼ 7000 の他のプロジェクトに依存しています。結果として、Log4jの脆弱性は、たまたまそれを使う他のシステムの脆弱性になるかもしれません。
アパッチ・ソフトウェア・ファウンデーションが6月に誇らしげに ページ ように、火星のデクステリティ・ヘリコプターの中にも存在しています。
一般的に、人は、ロギングツールが単に興味のあるデータを取り込んで、確実にそれをログに記録するべきだと考えるでしょう。log4jはこれをするようですが、間違いなくロギング・システムがすべきではないこともします：それは積極的にログに記録されるデータを解釈して、それに応じて行動します。それがすることができることの1つは、データのためにリモートサーバーに照会、ログメッセージにそれを組み込むことです。例えば、 LDAP サーバーから情報を取得し、ログに追加することができます。これは、特定のユーザーの詳細なアカウント情報のデータをログに含めたい場合に便利です。
しかし、リモート・ディレクトリ・サーバーが、実行のために再アセンブルできるJavaオブジェクトのような、より多くの形式のデータを提供できるという事実は、ロギング・ツールが単にいくつかのデータを記録することを期待していたのに対して、これを実行中のアプリケーションにコードを注入する方法に変えます。これは、元々ロギング・ツールが何らかのデータを記録することを望んでいたのに対し、この機能性を、実行中のアプリケーショ ンにコードを注入する方法へと変えます。この脆弱性を悪用するために、攻撃者は2つのことを行う必要があります：
関連するプロトコルを実行する、きちんと構築されたサーバーをセットアップすることで、攻撃対象のシステムがこのサーバーにアクセスできることが保証されます。LWNサーバーのログを調べると、DNSプロトコルを悪用しようとする試みもあることがわかります。
攻撃者が提供する特別な「マントラ」文字列をターゲットシステムに記録させ、悪意のあるサーバーからオブジェクトをロードして実行できるようにします。
上の2番目のステップは難しく見えるかもしれませんが、実はとても簡単です。多くのシステムは、ユーザから提供されたデータを喜んでログに記録します。これらの悪意のある文字列は、最終的にログに表示されるユーザー名として偽装されるかもしれませんし、ブラウザのユーザーエージェント文字列を偽装することもよくある選択です。ターゲットが餌に食いつき、悪意のある文字列をログに記録したら、ゲームは終わりです。
言い換えれば、これはインターネットから提供された未浄化のデータを直接使用した典型的なケースであり、予測可能な結果です。これは通常のレビュー・プロセスで発見されるはずです。悪意のある文字列がフロントエンド・ソフトウェアから内部システムに渡されることもあり、その場合、内部システムはその文字列をログに記録するかどうかを決定する可能性があることに注意してください。言い換えれば、単にインターネットに直接さらされないことは、必ずしもこの脆弱なシステムに対する十分な防御ではありません。Log4jを使用するすべてのシステムは、上記のリンクで提供された記事で説明されているように、アップグレードか何らかの他の緩和手段によって、修正される必要があります。初期の修正は、Log4jのすべての問題に対処するには不十分であることが証明されており、ユーザーは、 最新のアップデートでツールを最新に保つ必要があることに注意してください。
この脆弱性に対する反応は迅速かつ強力です。オープンソースは壊れている」と断言するコメンテーターもいます。もしあなたが xkcd #4327を 読んでいないなら、それはまさにあなたが今経験していることです。一部の人が主張するように、コミュニティに深刻な問題があるのでしょうか？要するに、このシーンは、オープンソースプロジェクトの2つのよく知られた欠点、依存性とメンテナに関連するものを実証しているようです。
多すぎる依存関係
フリーソフトウェアの黎明期には、まったく何もなかったので、ほとんどすべてをゼロから書かなければなりませんでした。その結果、当時は人々が無料でダウンロードして使えるパッケージがほとんどなかったので、どのプロジェクトも独自のセキュリティ脆弱性を書いていました。コミュニティはこの課題に直面し、人々がもっと無邪気だったその昔でさえ、セキュリティ問題は定期的に見られました。
私は、開発者や学者が再利用可能なソフトウェアの利点について話しているのと同じくらい長い間、この分野に没頭してきました。長年にわたり、この夢は実際に実現されてきました。多くの言語のコミュニティには、さまざまな一般的なタスクのためのモジュールが大量に集まっています。プログラムを書くことは、多くの場合、適切なモジュールを見つけ、それらを正しく組み合わせるだけの問題です。モジュール・リポジトリから自動的にダウンロードするために使われるこれらのインターフェースは、必要なモジュールを入手するすべてのプロセスを自動化しました。ずっと前に./configure を実行し、まだ準備ができていない次の依存モジュールを手動でインストールすることに慣れていた人たちにとって、最新の開発環境は古いやり方に対する圧勝です。最初のころは大変だったことも、今はそうではありません。
これはコミュニティにとって大きな成果です。数十年前にはまったく想像もできなかったような生産性で仕事を続けることができ、楽しく仕事ができる開発環境が整いました。しかし、ここに問題が潜んでいます。この構造により、プロジェクトは外部モジュールへの依存を蓄積しやすくなり、それぞれが何らかのリスクをもたらす可能性があるのです。インターネット上のランダムなコード片を自分のプログラムに直接インポートしているという事実は、多くの結果をもたらす可能性があります。おそらく、モジュールの1つは、単に悪意ある攻撃に開かれているモジュールであるかもしれません、おそらく、モジュールは単に消えます、あるいは、おそらく、Log4jの場合のように、それは単にもはや評価されず、保守されません。
しかし、たとえブランディングが将来的により高いレベルの信頼性を示すとしても、何百もの依存関係を持った後に安定性を維持するのは困難です。依存ライブラリは、採用された時点では堅固でメンテナンスが行き届いているように見えても、1年後、2年後にはあまり魅力的でなくなるかもしれません。しかし、このようなメンテナンスが行き届いていないプロジェクトは、何か深刻な問題が発生するまで気づかれないことが多いのです。そのようなプロジェクトのユーザーは、何か問題が起こってからでは遅いのです。ツールは依存関係の追加を簡単にしますが、既存の依存モジュールのメンテナンスの現状を評価する上ではあまり役に立ちません。
メンテナ
また、人々が大きく依存しているこれらのアイテムの開発やメンテナンスに対するサポートが不足しているという問題もあります。子犬は確かに素晴らしいが、誰かが注意を払わなければ、カーペットにおしっこをしたり、靴をかじったりしてしまう。フリーソフトウェアの自由な性質を利用して、強力なコードをたくさん含めるのは簡単ですが、依存関係はすべて、本当は注意する必要のある子犬なのです。
コミュニティとして、子犬を獲得する能力は、子犬を訓練する能力よりもはるかに重要です。様々な営利企業は常に提供されたソフトウェアを喜んで利用しますが、そのシステムの最も重要なコンポーネントに対して何らかの貢献やサポートをする必要性を感じません。実際、すべての企業がそうであり、自分たちが依存しているすべてのプロジェクトに対してサポートを提供できる企業はありません。フリーソフトウェアから、あなたがそれに注ぎ込める以上のものを得ることは、確かに良いことです。
とはいえ、エコシステムのビジネス・サイドは、実際のところ、フリー・ソフトウェアのこうした利点を当然のものと早合点すべきではありません。もし企業が自由ソフトウェアに基づいて重要な製品やサービスを構築するのであれば、そのソフトウェアが十分にサポートされていることを確認すべきですし、それを実現するために必要であれば、そのために一歩踏み出すべきです。一般的に、これは常に正しいことですが、行動とは程遠いものです。そうでなければ、Log4jのような危機が出現し続けるでしょう。今、多くの企業が気づいているように、そのような危機はコストがかかります。
「立ち上がる」とは、開発者と同じようにメンテナをサポートすることです。最悪の問題はしばしばメンテナ側にあります。Linuxカーネルのように、何千人もの開発者がその仕事に対して報酬を得ているプロジェクトでさえ、 です。よく言えば、企業はメンテナーの仕事は単なるオーバーヘッドだと考え、悪く言えば、メンテナーをサポートすることは競合他社を助けることだと考え、一般的には、それは他人の責任だと考えています。また、一般的に、メンテナの仕事は他人の責任だと考えています。社員がメンテナとして働くことに対して報酬を与える企業はほとんどないため、多くの社員が自分の時間を使ってやっているのが現状です。そして、その仕事は何百万ものダウンロードをもたらすかもしれませんが、このメンテナンス作業は実際には誰かの自由な時間に行われているのです。
このような問題は、フリーソフトウェア特有のものではありません。また、あるプロプライエタリなソフトウェアが、謳われているほど十分にサポートされていないということも、前代未聞のことではありません。自由ソフトウェアは、少なくとも、その作成者が協力的でなくても、修正することができます。しかし、コミュニティによって作成されたソフトウェアの量が膨大であるため、このような問題のいくつかはさらに悪化します。膨大な量のコードを保守しなければならないのに、多くのユーザはその手助けをする動機がないのです。おそらく将来のある時点で、これらの問題に対処できるようになるのでしょうが、その方法はまったく不明です。現時点では、サポートのないソフトウェアを火星に配備し続けることしかできないでしょう。
