オープンソースのジレンマ：イノベーション、セキュリティ、そして持続可能性のバランス
gpt.icon
Kazuhoは、OSSプロジェクトにおける機能や依存関係の無差別な追加がセキュリティリスクを生み出すこと、献身的な貢献者が必要であること、そしてOSSの成功には新しい機能の継続的な追加が不可欠であることを指摘しています。また、OSSの公開と共有の容易さは品質向上に寄与するが、同時にセキュリティ脆弱性の普及も許すと警鐘を鳴らしています。
gpt.iconKazuhoは、このインシデントがOSSコミュニティの努力の総合的な消耗や衰退を示すのではなく、OSSの採用とメンテナンスに関するより広範な問題を反映していると提案しています。
さらに、彼はOSSプロジェクトへの機能や依存関係の無差別な追加について批判し、systemd とその sshd との統合をケーススタディとして使用しています。Kazuhoによれば、sshd への攻撃は、ディストリビューションが sshd に systemd-inotify サポートを追加したことで、xz（liblzma）を介して無意図的に脆弱性が導入されたために可能になったとされます。彼は、systemd が伝統的なデタッチされたデーモン管理とその強化モードの両方をサポートするアプローチが、複雑さと潜在的なセキュリティ問題に寄与していると主張し、機能や依存関係を追加する際により抑制されたアプローチをとることで、そのようなリスクを軽減できると提案しています。
Kazuhoはまた、共有ライブラリに固有のリスクにも触れており、これらのライブラリへの依存を追加することで、ロード時に実行される初期化コードの実行により、任意のコード実行を許可する可能性があると指摘しています。この脆弱性は、間接的にロードされるライブラリにも広がっており、セキュリティ侵害の可能性を増幅させています。
これらの批判にもかかわらず、KazuhoはOSSの普及と成功を確保するためには、継続的な開発とイノベーションが必要であると認めています。彼は、Rubyの創設者であるYukihiro Matsumoto（Matz）による「泳ぎ続ける」ことの重要性についての声明を参照し、新しい課題に積極的に取り組み、「ノイズ」を生成し続けることで関連性と有用性を保つことが重要であると述べています。
最後に、KazuhoはOSSの公開と共有の容易さが、強みであると同時に潜在的な弱点でもあるという二重の性質について反省します。この開放性は協力と品質向上を促進しますが、同時に欠陥のあるまたは脆弱なソフトウェアの迅速な普及も許してしまいます。しかし、直ちに利益を期待せずにソースコードを共有する行為自体が品質の向上につながり、これによりOSSプロジェクトの全体的な価値と持続可能性に貢献していると彼は示唆しています。
これらの観察を通じて、KazuhoはOSSプロジェクトの管理、イノベーションとセキュリティのバランス、およびOSSの開かれた性質がソフトウェアの品質とコミュニティの回復力に与えるより広範な意味について、多面的な視点を提供しています。
kazuho 個人的には、疲弊してるんじゃなくて、OSSの性質上、必然の話だと思ってる。商用ソフトウェアならメンテコストが見合わなければそもそも公開しないし、メンテが困難になればクローズするけど、OSSのコードは公開しない理由少ないし、永久に残り続けるわけで… つまりは、第三者のOSSを採用する側の問題
>kinu: xz のバックドア、これは痺れるね…
攻撃者は zstd や lz4 もフォークしてて、どれが次でもおかしくなかった。OSS界は疲弊しており、技術力のある献身的な貢献者を歓迎しないと持続できない。根本のリスクはそこ。ifuncのリゾルバからフックし、特定条下で性能差を観測できる
kazuho で、対策としては、安易に機能や依存関係を増やさない、増やす場合はプラグインにして権限を分ける、とかだと思うけど、systemdがその反対の「あれもしたいこれもしたい」文化なのが、今回sshdへの攻撃が成立した原因じゃないの、と。そもそも… kazuho 1. 今回、xz (liblzma)を介してsshdに裏口を作れたのは、distro各社がsshdにsystemd-inotify対応を足してたから 2. systemd-inotifyはデーモンの起動完了を通知をする仕組みだけど、そもそも昔ながらの独自にデタッチする方式のデーモンの管理を「強化」するもの。デタッチしないデーモンなら不要...
kazuho ...だし、多くのデーモンはそれにも対応してる。systemdは、デタッチしない方式に統一・誘導すればよかったところ、両方式に対応しつつ、なおかつ、デタッチする方式も「強化」するという「あれもこれも」を選択 kazuho 3. systemd-inotifyのプロトコルは独自実装でも10行くらいなんだけど、これをライブラリ(libsystemd) を使うものとして提供した 4. * systemdがliblzmaに依存してるのはログの圧縮のためだけど、そんなの外部コマンド連携で十分（だしその方が柔軟だったんじゃないの？）
kazuho これらの要因が全て揃った結果、ssh起動時にlibsystemdを通してliblzmaがロードされ、そのタイミングでliblzmaの攻撃コードが動作するという条件が成立した kazuho 見逃されがちなのは、共有ライブラリ（.so）にはロード時に実行する初期化コードを埋め込むことができるので、ライブラリへの依存を追加した瞬間に、そのライブラリを呼ばない場合であっても、任意コード実行を許可することになる（そしてこれは間接にロードされるライブラリも含む）ってとこですね kazuho ただ、この見方が正しいとしても、OSSとして普及・成功するためには @yukihiro_matz
が指摘したように「泳ぎ続ける」（新しいことに取組みノイズを出し続ける）ことが大切で、新しい機能を追加し続けるっていうのはその解なんよね...
>kazuho: で、対策としては、安易に機能や依存関係を増やさない、増やす場合はプラグインにして権限を分ける、とかだと思うけど、systemdがその反対の「あれもしたいこれもしたい」文化なのが、今回sshdへの攻撃が成立した原因じゃないの、と。そもそも…
kazuho 別の言い方をすると、後先考えずに公開共有できるのがOSSの商用ソフトウェアに対するメリットで、それがゆえに、OSSが仮に品質に劣る悪貨だとしても良貨たる商用ソフトウェアを駆逐しつつあるんだろくらいの。 実際は収益化を諦めるがゆえにソースコード共有が可能になり、結果品質向上につながってる
>kazuho: 個人的には、疲弊してるんじゃなくて、OSSの性質上、必然の話だと思ってる。商用ソフトウェアならメンテコストが見合わなければそもそも公開しないし、メンテが困難になればクローズするけど、OSSのコードは公開しない理由少ないし、永久に残り続けるわけで…
つまりは、第三者のOSSを採用する側の問題 x.com/kinu/status/17…