Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
In go-libp2p, by using signed peer records a malicious actor can store an arbitrary amount of data in a remote node’s memory. This memory does not get garbage collected and so the victim can run out of memory and crash. It is feasible to do this at scale. An attacker would have to transfer ~1/2 as much memory it wants to occupy (2x amplification factor). The attacker can perform this attack over time as the target node’s memory will not be garbage collected. This can occur because when a signed peer record is received, only the signature validity check is performed but the sender signature is not checked. Signed peer records from randomly generated peers can be sent by a malicious actor. A target node will accept the peer record as long as the signature is valid, and then stored in the peer store. There is cleanup logic in the peer store that cleans up data when a peer disconnects, but this cleanup is never triggered for the fake peer (from which signed peer records were…
Recommended action: Upgrade to 0.27.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A malicious peer can use large RSA keys to run a resource exhaustion attack & force a node to spend time doing signature verification of the large key. This vulnerability is present in the core/crypto module of go-libp2p and can occur during the Noise handshake and the libp2p x509 extension verification step. To prevent this attack, go-libp2p now restricts RSA keys to <= 8192 bits. Patches Users should upgrade their go-libp2p versions to =v0.27.8, = v0.28.2, or =v0.29.1 To protect your application, it's necessary to update to these patch releases AND to use the updated Go compiler (1.20.7 or 1.19.12, respectively) Workarounds There are no known workarounds References The Golang crypto/tls package also had this vulnerability ("verifying certificate chains containing large RSA keys is slow” https://github.com/golang/go/issues/61460) Fix in golang/go crypto/tls: https://github.com/golang/go/commit/2350afd2e8ab054390e284c95d5b089c142db017 Fix in quic-go…
Recommended action: Upgrade to 0.29.1, 0.28.2 or 0.27.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Versions older than v0.18.0 of go-libp2p are vulnerable to targeted resource exhaustion attacks. These attacks target libp2p’s connection, stream, peer, and memory management. An attacker can cause the allocation of large amounts of memory, ultimately leading to the process getting killed by the host’s operating system. While a connection manager tasked with keeping the number of connections within manageable limits has been part of go-libp2p, this component was designed to handle the regular churn of peers, not a targeted resource exhaustion attack. In the original version of the attack, the malicious node would continue opening new streams on a stream multiplexer that doesn’t provide sufficient back pressure (yamux or mplex). It is easy to defend against this one attack, but there are countless variations of this attack: Opening streams and causing a non-trivial memory allocation (e.g., for multistream or protobuf parsing) Creating a lot of sybil nodes and opening new…
Recommended action: Upgrade to 0.18.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.