A critical denial-of-service vulnerability in libp2p-rendezvous lets any unauthenticated attacker exhaust a rendezvous server’s memory. Attackers spam DISCOVER requests, each generating a new pagination cookie stored without limits. This hits Rust implementations of the protocol, used for peer discovery in decentralized networks like IPFS and Ethereum clients.
Libp2p powers much of the decentralized web. Its rendezvous protocol lets nodes register services at central points—rendezvous servers—and query them for discovery. Unlike fully distributed DHTs, this relies on these servers as chokepoints. Expose one to the internet without safeguards, and it becomes a target. This flaw, rated high severity, exploits the server’s naive state management.
Technical Breakdown
The bug lives in how the server handles pagination for DISCOVER messages. It stores state in a HashMap<Cookie, HashSet<RegistrationId>>. When a peer sends DISCOVER, the server fetches matching registrations, generates a fresh cookie for the next page, and inserts it into the map. No cap exists. No eviction policy runs. Repeat indefinitely, and RAM balloons.
HashMap<Cookie, HashSet<RegistrationId>>
From the handler flow: remote peer issues DISCOVER, server calls registrations.get(...), crafts cookie, shoves it in Registrations::cookies. Each request adds entries. A single attacker crafting unique queries—for example, varying namespaces or pagination offsets—forces constant growth. Protocol-compliant traffic means no signature checks or anomalies trigger defenses.
Proof-of-concept awaits a private repo, but reproduction is straightforward: loop DISCOVER requests from a tool like curl or a libp2p client. Monitor server RSS climb. On a modest machine, gigabytes accumulate in minutes under sustained fire.
Attack Impact and Real-World Reach
Impacts any exposed rendezvous node. Network-reachable, zero auth, low complexity—anyone with internet pings it. Memory exhaustion crashes the server or swaps it to death, halting service discovery for dependent peers. In production, think IPFS gateways, Filecoin nodes, or Polkadot parachains using rendezvous for bootstrapping.
Why this matters: libp2p underpins billions in crypto value. Ethereum’s go-ethereum uses libp2p; IPFS clusters rely on it. A downed rendezvous server disrupts peer joins, file retrievals, even blockchain syncs. Attackers amplify with botnets—10Gbps isn’t needed, just request volume. No CVEs yet, but mirrors past P2P DoSes like IPFS’s ANNOUNCE floods.
Skeptical note: Not all deployments suffer equally. Internal clusters dodge it. But public rendezvous points? Prime targets. Audits missed this because it’s a resource exhaustion edge case, not injection or RCE. Still, operators must assume exposure.
Mitigations and Tradeoffs
Three fixes proposed. First: global cap like MAX_COOKIES_TRACKED (say, 10,000) with FIFO or TTL eviction. Simple, effective short-term. Downside: attackers churn cookies, flushing legit users’ pagination.
Second: stateless cookies. Bake state into signed, self-contained cookies. Peers carry their offset; server verifies without storage. Cleaner, scalable. Complexity rises—cookie size grows, forgery risks if crypto weak.
Third: rate limits or peer quotas. Track requests per IP or peer ID, cap cookies at 10/hour. Needs peer tracking, state itself. Easiest add-on: use tokio::time for sliding windows.
$ cargo add ratelimit-meter # For peer quotas
Patch now. Fork the repo, apply bounds. Monitor via Prometheus for map size. Run behind proxies with nginx rate limits as interim. Upstream fix likely soon—watch libp2p/rust-libp2p channels.
Bottom line: This exposes a core weakness in centralized discovery. P2P protocols need built-in DoS resistance. Relying on rendezvous? Diversify to Kademlia DHTs or add redundancy. Unpatched servers risk outage in hostile nets.
