Radicle: ネットワークプロトコルにおける脆弱性の開示

Radicleは、Gitを基盤としたピアツーピアのローカルファーストなコードコラボレーションスタックです。 概要 何が起こったのか？ Radicleノードが使用するネットワークプロトコルに、2件の重大なセキュリティ脆弱性が報告されました。 どのバージョンが影響を受けますか？ 現在までにリリースされたRadicleの全バージョンが脆弱です。 問題は何ですか？ ノード間のネットワークトラフィックは暗号化されておらず、認証もされていません。署名付き参照によるリポジトリコンテンツの認証は、2つのノード間のネットワークパス上の攻撃者が転送中のオブジェクトを変更した場合に検出できます。したがって、主な懸念は情報漏洩、つまり2つのノード間のネットワークパス上の攻撃者が転送中のオブジェクトを読み取ることです。公開リポジトリの場合、情報漏洩の懸念は少なくなります。しかし、転送中の暗号化はプライベートリポジトリにとって非常に重要です。 ユーザーはどうすべきですか？ 修正版がリリースされるまで、プライベートリポジトリの使用を停止することをお勧めします。 修正版はいつリリースされますか？ バージョンネゴシエーション機能の欠如と、修正がワイヤー上で互換性がないため、後方互換性のある緩和策は実現不可能であり、この問題を修正するリリースは破壊的なものになるため、メジャーバージョン番号が引き上げられます。この作業は進行中です。この開示により、私たちの目標は、まず第一に状況について正直かつ明確であることであり、ユーザーが評価してそれに応じて行動できるようにしながら、私たちは解決策に取り組んでいます。 脆弱性 Radicleが使用するネットワークプロトコルは、期待されていた機密性を提供しません。ノード間のネットワークパスを傍受できる人は誰でも、データがプレーンテキストで送信されるため、交換されるデータを読み取ることができます。これは、Konstantinos Maninakisによって2026-06-24に報告されました。彼の投稿はこちらで読むことができます: https://maninak.com/blog/radicle-cleartext-transport-vulnerability/。私たちはアップストリームに報告しました。この問題を参照してください。 接続ハンドシェイクにおけるピア認証が壊れており、なりすましを可能にします。攻撃者はあなたのノードに接続し、それ自身のノードIDではないものを提示できます。プライベートリポジトリは、許可リストに登録されたノードIDのみと共有されます。許可リストに登録されたノードIDを偽装した攻撃者は、ネットワークパス上にいなくても、プライベートリポジトリを直接フェッチできます。これはcryptocodeによって2026-08-12に報告されました。私たちはアップストリームに修正案を提案しました。プルリクエストを参照してください。 2番目の欠陥は、聞こえるほど単独で悪用するのは難しいです。許可リストに登録されたノードIDを偽装するには、攻撃者はまずそれを知っている必要があります。許可リストは公開されていないため、ネットワークパス上にいない攻撃者は推測する必要があります。実際には、2つの欠陥は一緒に悪用される場合に最も有用です。パス上の攻撃者は、接続の両端のノードIDを確認でき、どちらも通常は許可リストに登録されています。その攻撃者は、監視中に交換されたものをすべて読み取ることができ、その後、見たノードIDを使用してオンデマンドでリポジトリ全体をフェッチできます。現実的な脅威は、あなたのノードと同期しているノードの間のパス上の誰でもあり、設定や許可リストはそれらから保護しません。 セキュリティアップデートが利用可能になる前に、これを公開します。今日から行動できます。リリースされる修正が、すでに発生した露出を元に戻すことはできません。 回避策 セキュリティアップデートがリリースされるまで、プライベートリポジトリ（ネットワーク経由）の使用を停止してください。プライベートリポジトリのシードを停止してください（下記参照）。ただし、修正版がリリースされたら再びシードを開始できるように、プライベートリポジトリをストレージに保持しておくことをお勧めします（完全に削除しない）。ネットワーク経由で送信されたプライベートリポジトリはすべて漏洩したと見なしてください。もし機密情報、キー、またはトークンが暗号化されずに含まれていた場合は、それらをローテーションしてください。Tor、I2P、その他のオーバーレイネットワークやVPNソリューションなどの追加の暗号化されたトランスポートを使用しても、データを保護するには十分ではありません。それらは、2つのノード間のネットワークパス上の攻撃者からネットワークトラフィックを隠します。これにより攻撃対象領域が制限されるとしても、ピアのなりすましを防ぐことはできず、標的を絞った洗練された攻撃はプライベートリポジトリのコンテンツの漏洩につながる可能性があります。 プライベートリポジトリのシードを停止する方法 ストレージ内のプライベートリポジトリをリストします: rad ls --private --all 各リポジトリのシードポリシーを「ブロック」に変更します: rad block <RID> 注: ノードのシードポリシーが「許可」に設定されている場合、rad unseedの代わりにrad blockを使用することをお勧めします。rad unseedはリポジトリのシードポリシーを削除し、ノードはデフォルトポリシーにフォールバックします。デフォルトはブロックなので、デフォルト設定ではrad unseedで十分です。デフォルトのシードポリシーを「許可」に変更した場合、ノードはunseedした後もリポジトリを提供し続けます。rad blockは明示的なブロックを設定し、ノードはそれを最初にチェックするため、どちらの場合も機能します。 ノードを完全に停止するには: rad node stop これによって達成されることの3つの制限: リポジトリの提供を停止します。 ローカルコピーは削除されません。コピーは$(rad path)/storage/<RID（rad:プレフィックスなし）>に残ります。そのディレクトリを削除するのは、リポジトリとそのリポジトリのすべてのフォークを削除することを理解している場合のみです。不明な場合は、ストレージから削除しないでください。 許可されたピアがすでにフェッチしたコピーには到達しません。それらのピアはデータを保持しており、それらのノードは同じ欠陥を持っています。それらのピアにもリポジトリをブロックするように依頼してください。 過去の露出を元に戻しません。すでにネットワーク経由で同期されたデータは、開示されたものとして扱われるべきです。 何が影響を受けますか？ 両方の欠陥は、リポジトリデータモデルではなく、ノードトランスポートレイヤーにあります。Gitオブジェクトと署名付き参照は、これまでどおりストレージレイヤーで検証されます。攻撃者はコードやIDを偽造できません。機密性の欠陥は、現在までにリリースされたすべてのRadicleバージョンに存在していました。 解決策 私たちは積極的に解決策に取り組んでいます。解決策には、Radicleのネットワーキングプロトコル（現在はNoiseを使用するカスタムプロトコル）を、オープンスタンダードに基づいたオープンソースのピアツーピアネットワーキングスタックであるirohに置き換えることが含まれます。私たちはすでに移行計画を共有しており、脆弱性は私たちにさらに前進する理由を与えました。脆弱性に対処するだけでなく、irohはNATトラバーサルなどの追加機能をもたらし、Radicleネットワークの信頼性と回復力を向上させます。ネットワークトランスポートへのこのような変更は、本質的に後方互換性がありません。そのため、ネットワークはアップグレードされたクラスターとアップグレードされていないクラスターに分割され、互いに通信できません。これはメジャーリリースを意味しますが、ストレージレイアウトを互換性のある状態に保ちながら、ネットワークエンドに破損を集中させることで、アップグレードパスを可能な限りスムーズにするよう努めています。 謝辞 Konstantinos Maninakisとcryptocodeがこれらの脆弱性を責任を持って開示し、連絡を取り続けてくれたことに感謝します。セキュリティ上の問題をご報告になりたい場合は、https://radicle.dev/.well-known/security.txt を参照してください。