Marten-Seemann

An attacker can trigger excessive memory allocation in the HTTP/3 client and server implementations by sending a QPACK-encoded HEADERS frame. This frame decodes into a large trailer field section containing numerous unique field names or large values. The system constructs an `http.Header` for the `http.Request` or `http.Response` but only enforces limits on the size of the compressed HEADERS frame rather than the decoded field section. This discrepancy allows a maliciously crafted frame to expand up to 50 times its encoded size using QPACK static table entries, leading to memory exhaustion and a denial-of-service (DoS) state.

An attacker can cause unbounded memory consumption by repeatedly creating and closing many WebTransport streams. Closed streams were not removed from an internal session map, preventing garbage collection of their resources. A malicious peer can exploit this by opening and closing a large number of streams, leading to continuous memory growth proportional to the number of closed streams. The software maintains an internal map tracking WebTransport streams, and affected versions did not remove entries for closed streams from this map.

A malicious peer can cause a denial of service in webtransport-go by preventing or indefinitely delaying WebTransport session closure. Specifically, a peer can withhold QUIC flow control credit on the CONNECT stream, blocking transmission of the WT CLOSE SESSION capsule and causing the close operation to hang. The WebTransport protocol signals session termination by sending a WT CLOSE SESSION capsule on the CONNECT stream. Affected versions blocked indefinitely while waiting for sufficient QUIC flow control credit from the peer.

webtransport-go’s session implementation is susceptible to excessive memory consumption. An attacker can send a `WT CLOSE SESSION` capsule containing an excessively large Application Error Message. The implementation does not enforce the draft-mandated 1024-byte limit on this field, allowing an attacker to send an arbitrarily large message payload that is fully read and stored in memory. This allows an attacker to consume an arbitrary amount of memory, requiring the full payload transmission to achieve the memory consumption.

The loss recovery logic for path probe packets in quic-go can be exploited by a malicious QUIC client to trigger a nil-pointer dereference. This is achieved by sending valid QUIC packets from different remote addresses, triggering the path validation logic and causing the server to send path probe packets, followed by sending specifically crafted ACKs for packets received from the server.

Name of the Vulnerable Software and Affected Versions: quic-go versions prior to 0.48.2 Description: An off-path attacker can inject an ICMP Packet Too Large packet, disrupting a QUIC connection by setting the MTU value to smaller than 1200 bytes. This can be done after the handshake completion, circumventing any TCP fallback. The attacker needs to know the client's IP and port tuple to mount an attack. Recommendations: For versions prior to 0.48.2, upgrade to version 0.48.2 to fix the vulnerability. As a temporary workaround, consider using `IP PMTUDISC PROBE` instead of `IP PMTUDISC DO` to disable the kernel's MTU tracking. Alternatively, use iptables to drop ICMP Unreachable packets to minimize the risk of exploitation.

The issue is related to the QUIC protocol implementation in quic-go, where an attacker can cause its peer to run out of memory by sending a large number of `NEW CONNECTION ID` frames that retire old connection IDs. The receiver is supposed to respond to each retirement frame with a `RETIRE CONNECTION ID` frame. However, the attacker can prevent the receiver from sending out these `RETIRE CONNECTION ID` frames by collapsing the peer's congestion window and manipulating the peer's RTT estimate.

The issue is related to unbounded storage of information related to connection ID retirement, which could lead to excessive resource consumption. Each QUIC connection possesses a set of connection Identifiers (IDs). Endpoints declare the number of active connection IDs they are willing to support using the `active connection id limit` transport parameter. The peer can create new IDs using a "NEW CONNECTION ID" frame but must stay within the active ID limit. This is done by retirement of old IDs, the endpoint sends "NEW CONNECTION ID" includes a value in the `retire prior to` field, which elicits a "RETIRE CONNECTION ID" frame as confirmation. An unauthenticated remote attacker can exploit the issue by sending "NEW CONNECTION ID" frames and manipulating the connection so that "RETIRE CONNECTION ID" frames can only be sent at a slower rate than they are received, leading to storage of information related to connection IDs in an unbounded queue.

An attacker can cause its peer to run out of memory by sending a large number of `PATH CHALLENGE` frames. The receiver is supposed to respond to each `PATH CHALLENGE` frame with a `PATH RESPONSE` frame. However, the attacker can prevent the receiver from sending out most of these `PATH RESPONSE` frames by collapsing the peer's congestion window and manipulating the peer's RTT estimate.

The issue is related to unbounded queuing of path validation messages, which could lead to excessive resource consumption. QUIC path validation requires that the recipient of a `PATH CHALLENGE` frame responds by sending a `PATH RESPONSE`. An unauthenticated remote attacker can exploit this by sending `PATH CHALLENGE` frames and manipulating the connection, such as restricting the peer's congestion window size, so that `PATH RESPONSE` frames can only be sent at a slower rate than they are received, leading to storage of path validation data in an unbounded queue.

The QUIC stack, as used by h2o, is susceptible to a state exhaustion attack. When h2o is serving HTTP/3, a remote attacker can exploit this vulnerability to progressively increase the memory retained by the QUIC stack. This can eventually cause h2o to abort due to memory exhaustion. HTTP/1 and HTTP/2 are not affected by this vulnerability as they do not use QUIC.

The issue arises from serializing an ACK frame after the CRYPTO frame, allowing a node to complete the handshake. This can trigger a nil pointer dereference when the node attempts to drop the Handshake packet number space, leading to a panic. An attacker can bring down a quic-go node with minimal effort by completing the QUIC handshake, which requires sending and receiving only a few packets.

A malicious actor can store an arbitrary amount of data in a remote node's memory by sending the node a message with a signed peer record. This memory does not get garbage collected, and so the victim can run out of memory and crash. If users of go-libp2p in production are not monitoring memory consumption over time, it could be a silent attack, where the attacker could bring down nodes over a period of time, depending on the node resources. For example, a go-libp2p node on a virtual server with 4 GB of memory can be brought down in about 90 seconds.

A malicious peer can use large RSA keys to run a resource exhaustion attack and force a node to spend time doing signature verification of the large key. This issue 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.