CVE-2024-45311

Quinn is a pure-Rust, async-compatible implementation of the IETF QUIC transport protocol. As of quinn-proto 0.11, it is possible for a server to accept(), retry(), refuse(), or ignore() an Incoming connection. However, calling retry() on an unvalidated connection exposes the server to a likely panic in the following situations: 1. Calling refuse or ignore on the resulting validated connection, if a duplicate initial packet is received. This issue can go undetected until a server's refuse()/ignore() code path is exercised, such as to stop a denial of service attack. 2. Accepting when the initial packet for the resulting validated connection fails to decrypt or exhausts connection IDs, if a similar initial packet that successfully decrypts and doesn't exhaust connection IDs is received. This issue can go undetected if clients are well-behaved. The former situation was observed in a real application, while the latter is only theoretical.

Quinn is a pure-Rust, async-compatible implementation of the IETF QUIC transport protocol. As of quinn-proto 0.11, it is possible for a server to accept(), retry(), refuse(), or ignore() an Incoming connection. However, calling retry() on an unvalidated connection exposes the server to a likely panic in the following situations: 1. Calling refuse or ignore on the resulting validated connection, if a duplicate initial packet is received. This issue can go undetected until a server's refuse()/ignore() code path is exercised, such as to stop a denial of service attack. 2. Accepting when the initial packet for the resulting validated connection fails to decrypt or exhausts connection IDs, if a similar initial packet that successfully decrypts and doesn't exhaust connection IDs is received. This issue can go undetected if clients are well-behaved. The former situation was observed in a real application, while the latter is only theoretical.

Summary

As of quinn-proto 0.11, it is possible for a server to accept(), retry(), refuse(), or ignore() an Incoming connection. However, calling retry() on an unvalidated connection exposes the server to a likely panic in the following situations:

• Calling refuse or ignore on the resulting validated connection, if a duplicate initial packet is received
  • This issue can go undetected until a server's refuse()/ignore() code path is exercised, such as to stop a denial of service attack.
• Accepting when the initial packet for the resulting validated connection fails to decrypt or exhausts connection IDs, if a similar initial packet that successfully decrypts and doesn't exhaust connection IDs is received.
  • This issue can go undetected if clients are well-behaved.

The former situation was observed in a real application, while the latter is only theoretical.

Details

Location of panic: https://github.com/quinn-rs/quinn/blob/bb02a12a8435a7732a1d762783eeacbb7e50418e/quinn-proto/src/endpoint.rs#L213

Impact

Denial of service for internet-facing server

Quinn is a pure-Rust, async-compatible implementation of the IETF QUIC transport protocol. As of quinn-proto 0.11, it is possible for a server to accept(), retry(), refuse(), or ignore() an Incoming connection. However, calling retry() on an unvalidated connection exposes the server to a likely panic in the following situations: 1. Calling refuse or ignore on the resulting validated connection, if a duplicate initial packet is received. This issue can go undetected until a server's refuse()/ignore() code path is exercised, such as to stop a denial of service attack. 2. Accepting when the initial packet for the resulting validated connection fails to decrypt or exhausts connection IDs, if a similar initial packet that successfully decrypts and doesn't exhaust connection IDs is received. This issue can go undetected if clients are well-behaved. The former situation was observed in a real application, while the latter is only theoretical.

Quinn is a pure-Rust, async-compatible implementation of the IETF QUIC transport protocol. As of quinn-proto 0.11, it is possible for a server to accept(), retry(), refuse(), or ignore() an Incoming connection. However, calling retry() on an unvalidated connection exposes the server to a likely panic in the following situations: 1. Calling refuse or ignore on the resulting validated connection, if a duplicate initial packet is received. This issue can go undetected until a server's refuse()/ignore() code path is exercised, such as to stop a denial of service attack. 2. Accepting when the initial packet for the resulting validated connection fails to decrypt or exhausts connection IDs, if a similar initial packet that successfully decrypts and doesn't exhaust connection IDs is received. This issue can go undetected if clients are well-behaved. The former situation was observed in a real application, while the latter is only theoretical.

Summary

As of quinn-proto 0.11, it is possible for a server to accept(), retry(), refuse(), or ignore() an Incoming connection. However, calling retry() on an unvalidated connection exposes the server to a likely panic in the following situations:

• Calling refuse or ignore on the resulting validated connection, if a duplicate initial packet is received
  • This issue can go undetected until a server's refuse()/ignore() code path is exercised, such as to stop a denial of service attack.
• Accepting when the initial packet for the resulting validated connection fails to decrypt or exhausts connection IDs, if a similar initial packet that successfully decrypts and doesn't exhaust connection IDs is received.
  • This issue can go undetected if clients are well-behaved.

The former situation was observed in a real application, while the latter is only theoretical.

Details

Location of panic: https://github.com/quinn-rs/quinn/blob/bb02a12a8435a7732a1d762783eeacbb7e50418e/quinn-proto/src/endpoint.rs#L213

Impact

Denial of service for internet-facing server

In 0.11.0, we overhauled the server-side Endpoint implementation to enable more careful handling of incoming connection attempts. However, some of the code paths that cleaned up state after connection attempts were processed confused the initial destination connection ID with the destination connection ID of a substantial package. This resulted in the internal Endpoint state becoming inconsistent, which could then lead to a panic.

https://github.com/quinn-rs/quinn/commit/e01609ccd8738bd438d86fa7185a0f85598cb58f

Thanks to @finbear for reporting and investingating, and to @BiagoFesta for coordinating.