OpenSSH と XZ/liblzma: 国家による攻撃を阻止した、私たちは何を学びましたか?

私は最近、冷戦の偏執狂的な時代にレーガンのアメリカで普通のアメリカ人家族に変装して暮らすKGBの覆面工作員についての10年前のテレビシリーズ「 アメリカ人」を見ています。 今週末に、同じように影のあるID( CVE-2024 3094- )を持つエージェントによってオープンソースメンテナに対して実行されているのと同じタイプの操作の メーリングリストの投稿 を読むことになるとは思っていませんでした。

The Grugq が説明しているように、「JK ペルソナは、何ヶ月にもわたって複数のスレッドで Lasse (メンテナ) を追い詰めます。ラッセにとって幸運なことに、彼の新しい友人でありスター開発者であり、さらに幸運なことに、ジア・タンはメンテナンス作業を手伝う時間があります。 なんという幸運でしょう! これはまさに、HUMINT組織がエージェントを配置するために実行する運用スタイルです。 彼らは誰かを配置し、ターゲットに危機を作り出し、エージェントが解決できる危機を作ります。

この作戦は2年以上に渡り、エージェントを配置し、攻撃のためのインフラストラクチャをセットアップし、さまざまなツールから隠蔽し、この攻撃を機能させる systemdの最近の変更 が出荷される前に、Linuxディストリビューションへの導入を急ぎました。

同様にありそうもない事故は、PostgresのメンテナであるAndres Freundが、おそらく偶発的なパフォーマンスの低下から、大部分のシステムに到達する前に 攻撃を発見した ときに発生しました。 アンドレスは言う、 「SSHなどでログインしているときも気づかなかった。 当時、私はマイクロベンチマークを行っており、ノイズを減らすためにシステムを静止させようとしていました。 sshdプロセスは、ユーザー名が間違っているなどが原因ですぐに失敗したにもかかわらず、驚くほど多くのCPUを使用していました。 sshd のプロファイルを作成しました。 これは、perfがそれをシンボルに帰属させることができず、dsoがliblzmaとして表示されるコードで多くのCPU時間を示しました。 不審に思った。 それから、数週間前にいくつかのパッケージアップデートがインストールされた後、Postgresの自動テストで奇妙なvalgrindの苦情を見たことを思い出しました。 本当に多くの偶然が必要でした」 

この脆弱性を検出するツールがないため、私たちがここにいたことがどれほど幸運だったかを誇張するのは難しいです。 事後的にも、脆弱性を引き起こすために必要な秘密鍵がなく、コードが非常にうまく隠されているため、外部から検出することはできません。 Linusの法則は「十分な目玉があれば、すべてのバグは浅い」と述べられていますが、過去にはこれが常に正しいとは限らないか、今回うまくいったとしても、使用するすべてのコードを見る目玉が足りないことがわかっています。

即時のアクションに関しては、この攻撃はsystemdと統合するためにパッチが適用されたOpenSSHサーバーのサブセットを標的にしたようです。 コンテナでSSHサーバーを実行することは稀であり、最初の優先事項はコンテナホストであるべきですが、問題は早期に発見されたため、更新する人はほとんどいない可能性があります。 過去 2 年間のコミットが調査されるにつれて、エクスプロイトが配置された xz 圧縮ライブラリである liblzma に一連の修正が行われていますが、現在のところ、OpenSSH 以外のソフトウェアにエクスプロイトが含まれているという証拠はありません。 Docker Scout の Web インターフェイスでは、パッケージ名で "lzma" を検索でき、問題は "high profile vulnerabilities" ポリシーでフラグが立てられます。

非常に多くのコメンテーターがシンプルな技術的ソリューションを持っており、非常に多くのベンダーがこれを使用してツールをプッシュしています。 技術コミュニティとして、私たちはこのような問題に対する技術的な解決策を望んでいます。 ベンダーは、このようなイベントの後、誰もそれを検出していないにもかかわらず、製品を販売したいと考えています。 Rustで書き直し、 autotoolsを撃ち、GitHubのtarballの使用を停止し、アーティファクトをチェックインするなど、リストは続きます。 これらは悪いことではなく、理解と明確さがセキュリティにとって価値があることは間違いありませんが、多くの場合、パフォーマンスと引き換えにします。 m4 や autotools は読みにくく、理解しにくいものですが、ifunc のようなツールでは、ほとんど静的なエコシステムでも動的なディスパッチが可能です。 これらの問題を解決するためにエコシステムに多額の投資を行う価値はありますが、攻撃者は単に新しいベクトルや 奇妙なマシンを見つけるだけであることがわかっています。 同様に、オープンソース開発者のIDを持つことで問題が解決するかのように、国家機関が偽のIDを簡単に見つけたり、信頼できない人々に「ノーと言う」ことができるのに、秘密にしておきたいと願う非常に純粋な人々がいる場合、人々に関する多くの素朴な提案があります。 安易な解決策を持ち込む人には注意してください、このホットテイクの世界にはたくさんの人がいます。

ここからどこへ向かうのか? 認識とオブザーバビリティを第一に考えます。 この場合に見られるように、ハイパーアウェアネスでさえ、小さな手がかりが重要です。 次回は違うので、この攻撃の正確な詳細に焦点を当てるのではなく、より一般的に考えてください。 まず、組織のソフトウェアの使用状況、サプライチェーン、重要なポイントを理解することから始めます。 違いを生むために、何に資金を投入すべきかを尋ねます。 次に、レジリエンスを構築します。 多層防御と多様性 — 単一文化ではありません。 OpenSSH は広く普及しており、OpenBSD の開発者は素晴らしい仕事をしており、そのために彼らの上流が標的にされたので、OpenSSH は常に標的になります。 しかし、複数の強力なソリューションを備えた多様なエコシステムが必要であり、組織として重要なソフトウェアのセカンドサプライヤーが必要です。 この時代のセキュリティの 3 つ目の重要な部分は、回復性です。 最悪のケースが起こったシナリオを計画し、結果と回復プロセスを理解することは、今の全員の宿題であり、ゼロ日前後の机上演習で準備していることを確認してください。 

これは、私たち全員がオープンソースのサプライチェーンを強化するために引き続き協力し、次にこれが起こったときの回復力に取り組む機会です。 私たちは、 Dockerコミュニティ内での対話と議論を奨励しています。

さらに詳しく

• Docker Scout ダッシュボード: https://scout.docker.com/vulnerabilities/id/CVE2024-3094
• NIST の CVE: https://nvd.nist.gov/vuln/detail/CVE-2024-3094