バックドアの偶然の発見により、数千件の感染が防止された可能性がある

[投稿は Deepfactor に最初に掲載されました] 昨日の xz バックドアの発見は偶然でした。しかし、それはなんと幸運な事故だったのでしょうか。その俳優（または俳優、まだわかりません）は、長い間熱心に努力してきましたが、つい最近になってすべての要素をまとめ始め、最終的に昨日発見されました。バックドアは誤って「ssh バックドア」と呼ばれています。これは少し誤解を招きます。 OpenSSH は xz 自体を使用しませんが、Linux ディストリビューションの管理者は、構築時に xz を sshd にリンクしました (表向きには systemd との統合を容易にするため)。実際のところ、xz は非常に多くのパッケージにリンクされているため、バックドアが行った可能性のある範囲を完全に確認することは決して不可能かもしれません。

「私はセキュリティ研究者ではありませんし、リバース エンジニアでもありません。」 Andres Freund は、いくつかの奇妙な ssh パフォーマンスの問題と valgrind のクラッシュのテスト中にバックドアが発見されたと oss-security メーリング リストに投稿しました。アンドレス氏はセキュリティ研究者ではないことに注意することが重要です (このセクションのタイトルは、開示情報の中でアンドレス氏が書いたものです)。つまり、これは積極的に探していたものではなく、偶然見つけたものです。

これは信じられないほど幸運な発見でした。前述したように、xz はどこでも使用されます。 ssh がターゲットである可能性は高いですが、それは決して分からないかもしれません。バックドアは、xz のconfigure スクリプトに導入された難読化されたわかりにくい変更を介して、コードを liblzma に挿入しました。この変更の意図は、事前に構築されたいくつかの .xz ファイルをテスト バイナリとして使用することで、テストを改善することでした。実際には、これらのテスト バイナリには、sshd に挿入されたコードが含まれていました。

正直に言いましょう。自分で構築したすべての依存関係について、各設定スクリプトを検査している開発者は何人いますか? Libtool、autoconf、automake、および friends は、これらの構成スクリプトを手動で検査する必要がないように特別に作成されました (この場合、誰も検査しませんでした)。おそらくさらに悪いことに、サードパーティからの依存関係に依存している場合、サードパーティがそれを熱心に行っていると本当に信頼できますか?

これらの変更は、「Jia Tan」（おそらく本名ではなく、個人または国家のグループである可能性もあります）によってゆっくりと導入され、過去数年間に他の偽アカウントが表示され、変更を奨励しました。これは確かに、長いゲームをプレイする個人またはグループの行為でした。

2月下旬、「Jia Tan」が他のLinuxディストリビューション管理者に接近し、「素晴らしい新機能」を装ってxzのバックドアバージョンをディストリビューションに含めるよう圧力をかけたと報告されている。何年にもわたって基本的に機能が完成してきたライブラリである xz に、なぜ「素晴らしい新機能」が必要なのかは私にはわかりませんが、それはこれです。それにもかかわらず、バックドアライブラリはローリングリリース配布や他のライブラリのプレビューバージョンに侵入し始めました。

そして、私たち全員がバックドアを発見したのは本当に幸運でした。もしバックドアによって valgrind エラーや SSH パフォーマンスの問題が引き起こされていなければ、今から 6 か月後には、新しい配布バージョンに徐々にアップグレードされる際に、数千台のマシンが侵害されることに直面していたかもしれません。結局のところ、いくつかのディストリビューションには影響を受けたライブラリが含まれていましたが、ほとんどの場合、エコシステムはより大きな災害を免れました。

すべてのものを sshd にリンクする OpenSSH プロジェクトから提供される Base OpenSSH は、デフォルトの機能にサードパーティのライブラリを必要としません。おそらく未知のビジネス上の動機により、一部のディストリビューションの sshd は、「機能の向上」を装ってライブラリのユニバースにリンクされています。このように依存関係がアプリケーションにリンクされるたびに、アプリケーションはその依存関係のすべてのバグと問題を継承します。この場合、xz をリンクする理由は、sshd を systemd によってより簡単に制御できるようにするためだと考えられます。この決定により、これらのディストリビューションがバックドアにさらされることになりました。 systemd が Linux 世界をゆっくりと消費していくにつれて、このようなことがますます増えていくでしょう。

私自身の実験 このブログを書くための実験として、いくつかの VM を起動し、それぞれの VM の sshd にリンクされている外部ライブラリの数を調べました。その結果には私は驚きましたが、それほど驚かなくてもよかったのではないかと思います。

|配布 | sshd のライブラリ依存関係の数 | |----------------------|-------------------------- ----------------| | OpenBSD 7.5 (ベースライン) | 4 | |アルパイン Linux 3.19 | 4 | | Gentoo | 5 (*) | | Oracle Linux 9.1 | 26 | |ロッキー Linux 9.2 | 26 | | Ubuntu 22.04 | 26 | | CentOS 8 | 30 | | CentOS 7 | 47 |

(*) Gentoo の場合、デフォルトの USE 設定 (たとえば、ハンドブックに記載されているものを使用する) を使用して openssh ebuild を作成しました。 USE 設定によっては、これが大きくなる場合があります。私の Gentoo インストールは systemd ではなく OpenRC を使用していました。

前の表の値は、openssh sshd バイナリに対して ldd を実行し、ld.so、vdso エントリ、バイナリ自体などの一般的なもののカウントを差し引くことによって収集されました。

注: 一般に、信頼できないバイナリに対して ldd を実行しないでください。私のテストは、まさにこの理由から、使い捨ての分離された VM で実行されました。

ご覧のとおり、一部のディストリビューションは libc や pthread などにリンクするだけの非常に薄い sshd バイナリを出荷しますが、他のディストリビューションは単純にユニバース全体をバイナリにリンクします。確かに、リストされているディストリビューションの一部 (CentOS 7 など) は非常に古く、EOL が近づいているか、EOL を過ぎていますが、薄さやセキュリティ フットプリントの小ささを重視するディストリビューションと、そうでないディストリビューションの間には大きな差があることがわかります。時間の経過とともにその数は減少しているように見えますが、これらの「肥大化した」ディストリビューションの中で最も薄い sshd であっても、リスト内の最も薄いものよりも 5 ～ 6 倍の依存関係の数がリンクされています。

「自分が持っていないコードにバグがあるはずがない」 膨大な依存関係のリスト内でリンクする場合の問題の 1 つは、たとえその依存関係の機能が必要でなくても、それぞれに関連付けられた脆弱性に悩まされることです。これにより、アプリケーションの脆弱性の追跡とパッチ適用が必要以上に困難になります。たとえば、上記のディストリビューションの一部は、Kerberos およびスマート カード ログインをサポートするために sshd ライブラリにリンクされています。それが必要なインストールは何件ありますか? 5%? 10％？それにもかかわらず、考えられるすべてのビジネス ユースケースをカバーするために、これらのディストリビューションでは、念のため全員がそのサポートを受けることを決定しました。これにより、これらのライブラリの脆弱性がコミュニティ全体に公開されることになります。

それで、何ができるでしょうか？ディストリビューションのメンテナーから独立して独自の sshd を構築しようとする人はほとんどいません。その道を歩むと、他にも多くの問題が発生するからです。したがって、私たちは基本的に、私たちには何の落ち度もないのに、脆弱性がある可能性のあるパッケージに悩まされています。

ヘルプ！ Deepfactor で行っていることの 1 つは、ランタイム使用状況分析に基づいて、お客様が脆弱性に対する姿勢と修復の優先順位を理解できるよう支援することです。どの脆弱な依存関係がメモリにロードされて実行されたかを具体的に通知できるため、このような問題が発生した場合、最も重要な修復策をリストの先頭にすぐに追加できます。逆に、何が使用されていないのかもお知らせできるので、そのような地雷を環境から取り除くことができます。従来の SCA ツール (これらを SCA 1.0 と呼びます) は、環境内でどのような依存関係があるかをリストすることはできますが、実際に何が使用されているかを知ることはできません。これはこの場合重要です。

最終的な考え この種のサプライチェーン攻撃は、メンテナがメンテナンスに興味を失ったか、コードを完全に放棄したリポジトリを広く使用している限り、今後も続くと信じています。 xz 以外にも、このカテゴリに分類されるオープン ソース ライブラリは数多くあり、現在広く使用されているライブラリが維持されているとしても、それが継続されるという保証はありません。メンテナがコードのメンテナンスに興味を失い、ランダムな人が現れてメンテナンスを引き継ぐことに興味を示した場合、元のメンテナはなぜ「わかりました、頑張ってください」と言わないのでしょうか?この問題が解決されるまで (そして解決されるかどうかはわかりませんが)、Deepfactor のようなツールは、どの程度危険にさらされているか、問題を修正する必要がある順序を通知することで、ユーザーを保護するのに役立つことがわかります。

著者

Ai Base Network (ABN), ABN ASIAは、アカデミアに深く関わり、アメリカ、オランダ、ハンガリー、日本、韓国、シンガポール、ベトナムでの仕事経験を持つ人々によって設立されました。ABN ASIAは、学問とテクノロジーが機会と出会う場所です。最先端のソリューションと優れたソフトウェア開発サービスにより、ビジネスがレベルアップし、グローバルシーンに挑戦できるよう支援しています。 私たちの取り組み: より速く。 より良い。 より信頼性が高くなります。 ほとんどの場合、価格も安くなります。

いつでも、ITサービス、デジタルコンサルティング、既製のソフトウェアソリューション、または提案依頼書（RFP）をお探しの際は、お気軽にお問い合わせください。お問い合わせ先は[email protected]です。お客様のテクノロジーに関するニーズにお応えします。

© ABN ASIA