Radicle: Disclosure of Vulnerability in the Network Protocol

以下正文同步自 Hacker News，版权归原站所有，已转换为易读排版。

Radicle is a peer-to-peer, local-first code

collaboration stack built on Git.

Two critical security vulnerabilities in the network protocol used by Radicle nodes were reported.

All versions of Radicle that were released to date are vulnerable.

Network traffic between nodes is not encrypted and not authenticated.

Authentication of repository contents via Signed References still detects if attackers along the network path between two nodes modify objects in transit.

Thus, the main concern is information leakage, i.e., attackers along the network path between two nodes reading objects in transit.

For public repositories, information leakage is less of a concern.

However, encryption in transit is crucial for private repositories.

We recommend to stop using private repositories until a fix is released.

Due to a lack of version negotiation features, combined with the fix being incompatible on the wire, a backward compatible mitigation is not feasible; that means the release to fix this issue will be breaking, thus bump the major version number.

Work towards this is under way.

With this disclosure, our goal is, first and foremost, to be honest and clear about the situation, so that users can assess and act accordingly, while we are working on a resolution.

The second flaw is harder to exploit on its own than it sounds. To impersonate an allow-listed Node ID, an attacker must first know one. The allow-list is not public, so an attacker who is not on the network path has to guess.

In practice, the two flaws are most useful when they can be exploited together: an attacker on the path sees the Node IDs at both ends of a connection, and both are normally on the allow-list.

That attacker can read whatever is exchanged while they watch, and can then use a Node ID they saw to fetch the whole repository on demand.

The realistic threat is anyone on the path between your node and node it syncs with, and no setting or allow-list protects against them.

We are publishing this before the security update is available. You can act on it today, and no fix we release later can undo an exposure that has already happened.

List the private repositories in storage:

rad ls --private --all

Change the seeding policy of very individual repository to “block”:

rad block <RID>

Note: We recommend to use rad block instead of rad unseed, in case the seeding policy of your node is set to allow.

rad unseed removes the seeding policy for a repository, and your node then falls back to its default policy.

The default is block, so on a default configuration rad unseed is enough.

If you changed the default seeding policy to allow, your node keeps serving the repository after you unseed it.

rad block sets an explicit block, which the node checks first, so it works either way.

rad node stop

Three limits on what this achieves:

Both flaws are in the node transport layer, not in the repository data model. Git objects and signed references are verified at the storage layer as before. An attacker cannot forge code or identities.

The confidentiality flaw has been present in every Radicle version released to date.

The resolution involves replacing Radicle’s networking protocol (currently a custom protocol using Noise) with iroh, an open source peer-to-peer networking stack built on open standards. We already shared out plans to migrate, and the vulnerabilities have given us all the more reason to move forward with this. Beyond addressing the vulnerabilities, iroh brings additional features like NAT traversal which improve the reliability and resilience of the Radicle network.

Such a change to the network transport is by its nature backwards-incompatible. As such, it causes the network to partition into the upgraded and non-upgraded clusters that can not communicate with each other.

Even though this means a major release, we are working to make the upgrade path as smooth as possible, by focusing breakage on the network end, keeping storage layout compatible.

We would like to thank Konstantinos Maninakis and cryptocode for responsibly disclosing these vulnerabilities to us and staying in touch.

If you would like to report a security issue, please refer to https://radicle.dev/.well-known/security.txt.

正文由 FLUX 从来源站点 RSS 同步，内容未经改写；遇到排版缺失或需要图片、视频时请以原文为准。