オープンソースプロジェクト内の相互作用の縮図である xz バックドア問題

• xz/liblzma の脆弱性については多くの分析があるが、その大半は攻撃の第1段階を飛ばしがちである
  • 元のメンテナーが燃え尽き、攻撃者だけが支援を申し出た（そのため攻撃者は元のメンテナーが築いた信頼を引き継ぐことになった）。
• メールスレッドのアーカイブには、このステージ0が起きていた時点の状況が記録されている

メンテナーの燃え尽きと攻撃者の登場

• メンテナーにとってもっともらしく見える要望が出される

  • 「XZ for Java はまだメンテナンスされていますか？ 1週間前に質問を投稿したのですが、返答がありません」

• この質問は、メンテナーに「失敗」を認めさせることになる
  • 実際にはメンテナーは何も負っておらず、失敗したわけでもないが、そう感じてしまう
  • 「コミュニティ」を失望させるのは恐ろしいことだからだ
• メンテナーは自分が「遅れている」と認め、助けを求めているかのようなシグナルを送る
• しかしそのスレッドでは助けは現れず、代わりに xz/liblzma の攻撃者が自分は支援していると紹介される

  • 「Jia Tan（今回の攻撃者）が私を手伝ってくれており…今後さらに大きな役割を担うかもしれません…私のリソースはあまりに限られているので、長期的には何かを変えなければならないのは明らかです。」

• メンテナーは、自分のリソースが限られており、長期的には何らかの変化が必要だと述べる

非協力的な利用者の登場

• 非協力的な利用者がメンテナーに批判的な発言をする

  • 「新しいメンテナーが現れるまでは進展はなさそうです。…現在の管理者は関心を失ったか、もはやメンテナンスを気にしていません。このようなリポジトリを見るのは悲しいことです。」

• メンテナーは、自分は関心を失っていないが、メンタルヘルスの問題などにより管理能力が制限されていると弁明する
• メンテナーはまた、これは無償の趣味プロジェクトであることを改めて伝える

要求の増大

• 1週間後、非協力的な利用者が再び現れ、メンテナーを非難する。

  • 「あなたはこのメーリングリストで少しずつ腐っていっている数多くのパッチを無視しています。」

  • 「メンタルヘルスの問題については気の毒ですが、自分の限界を認識することが重要です。このプロジェクトがすべての貢献者にとって趣味プロジェクトであることは分かりますが、コミュニティはもっと多くを求めています。」

• その要望者は提案もするが、実際に支援するという申し出はない

  • 「XZ for C のメンテナンス権限を譲って、XZ for Java にもっと集中できるようにしてはどうでしょうか？ あるいは XZ for Java を他の誰かに渡して、XZ for C に集中できるようにしてはどうでしょうか？ 両方を維持しようとすると、どちらも十分に保守されないかもしれません。」

• メンテナーは、新しい共同メンテナーを見つけたり、プロジェクトを完全に引き渡したりするのは簡単ではないと説明する

オープンソースプロジェクトの現実

• ソフトウェア開発者は、都合よく抜き差しできる歯車ではない
• メールスレッドは、不満を述べる利用者が要求を続けながら何の支援も提供せず、攻撃者だけが残る形で終わる

  • 「Jia Tan は今後、プロジェクトでより大きな役割を担うかもしれません。彼はリスト外で多くの支援をしており、実質的にはすでに共同管理者です。:-)」

• このメールスレッドは、オープンソースプロジェクトにおける相互作用の縮図を示している
• 利用者はメンテナーに要求を突きつけ、メンテナーはストレスや燃え尽きによってさまざまに反応する
• このあり方には変化が必要である

[GN⁺]

Hacker Newsの意見

• 開発者がユーザーに親切であろうと努め、コメント投稿者の善意を汲み取ろうとすると、多くの精神的エネルギーを浪費してしまうように見えるという意見がある。こうした話は主に、趣味で進めているサイドプロジェクト（エミュレーター、ゲームのリメイクなど）で出てくる。これらのプロジェクトは、寄付金や著作権の問題を避けるため、寄付への言及を避けている。プロジェクトへの関心は高いが、実際に貢献できる熟練した関心はごく限られている。ユーザー同士の会話は許可され、奨励されているが、ときには開発者のやる気を削ぐ「提案」や「要求」と受け取られることがある。コミュニティを維持することは重要だが、直接貢献しない人々を排除しないことへの懸念もある。

• オープンソースプロジェクトの開発者が、攻撃者により多くのリポジトリ制御権を渡すよう圧力をかけられたソーシャルエンジニアリング攻撃が、問題の第一段階だった。

• セキュリティ志向のオープンソースライブラリのメンテナーとして、PRを読むたびに「この人は助けようとしているのか、それとも利用しようとしているのか」という疑念が重くのしかかる。開発速度を落とすことが唯一の解決策だと思うが、そのことで感じる気持ちは記事に出ていたものと同じだ。信頼できる専門家コミュニティに助けを求められる簡単な方法があるなら、いつでも歓迎したい。

• 暗号資産、AI、そして今回の事件のように、最大の問題は結局のところ信頼の問題に行き着く。暗号資産は信頼の問題をコードで解決しようとし、LLMは信頼を得るために見栄えの良さで人を欺こうとし、攻撃者は信頼のロンダリングにある程度成功した。最も重要な技術者たちが信頼について十分に考えられていない。この件では、疲弊した無償のオープンソース開発者に理解を示している。

• ポートノッキングが設定されたSSHサーバーがこのバックドアから安全かどうかという質問がある。RCEはSSHサーバーに接続した後でしか実行できないため、妥当なTCP/UDPノッキングシーケンスの後ろにポートが隠されているなら、問題は起きないように思われる。ポートノッキングは適切なSSH設定の代替にはならないが、SSHの脆弱性が現れた際に予防したり対応時間を稼いだりする追加の防御層として有用だ。

• OpenSSHのLinux固有パッチに関連する問題へのリンクがある。このパッチがなければ問題は起きなかったはずだ。これはOpenSSHの問題ではなく、Linuxの問題だ。

• people が left-pad事件の後でも、ハード依存関係と複雑性を相変わらず軽視しているという意見がある。OpenSSHはコードの巨大な壁だ。複雑なシステムは、どの言語で書かれていようと、本質的に信頼しにくい。

• 中国のハッカーが悪意ある行動をしようとするなら、なぜ中国風の名前/ハンドルを使うのか。オープンソースのメンテナーからより多くの信頼を得るには、英語圏/ヨーロッパ風の名前を使うほうがよいだろう。逆に、中国人ではないハッカーが悪意ある行動をしようとするなら、中国風の名前を使うほうがもっと理にかなっている（中国は悪だ、など）。

• Jigar Kumarアカウントはソーシャルエンジニアリング攻撃の一部に見え、非常に疑わしくあるべきだ。

• ソフトウェア開発者は交換可能な部品ではなく、コミュニティでコメントしたり参加したりする権限を制限することを考えている。たとえば、GitHubが「ゲート」を導入するなら、最初のゲートは、テストスイートにバージョン番号とテスト出力のハッシュを生成するテストを追加することかもしれない。この番号をプロフィールに追加すれば、GitHubはそのユーザーが少なくとも make test をダウンロードして実行したと信頼できる。これは一定のコミットメントを示す。