🇰🇷 한글 설명
악의적인 원격 피어가 NEW_CONNECTION_ID 프레임을 과도하게 전송하여 로컬 QUIC 스택의 리소스 제한 검사를 우회할 수 있는 취약점입니다. 공격자가 ACK를 전송하지 않을 경우, 로컬 스택은 RETIRE_CONN_ID 프레임을 처리하기 위해 제어 프레임 큐(CFQ)에 과도한 메모리를 할당하게 되어 약 400MB의 메모리 점유를 유발할 수 있습니다.
💡 쉬운 설명
해커가 가짜 연결 정보를 계속 보내서 컴퓨터의 메모리를 강제로 가득 채우게 만드는 공격입니다. 이로 인해 시스템의 메모리가 부족해져 서비스가 느려지거나 멈출 수 있습니다.
🇺🇸 원문 (English)
Issue summary: A malicious remote peer may flood the local QUIC
stack with NEW_CONNECTION_ID frames by avoiding a limit check on
how many connection IDs the remote QUIC stack can use.
Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame
for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID
frame is dispatched via the Control Frame Queue (CFQ). If the remote
peer also withholds ACKs, then it can force the local stack
to allocate ~400MB (depending on ACK delay).
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism
by which a remote peer can notify the local QUIC stack to change the
destination connection ID (a.k.a. CID) the local stack uses to
identify the connection at the remote peer. Each CID is associated
with a sequence number. The sequence number is transmitted
in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID
which is being either associated with a connection or retired.
The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know
a new CID is being associated with an existing connection. The
NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the
retire-prior-to number. The retire-prior-to identifies existing
CIDs that are to be retired. The local QUIC stack must send a
RETIRE_CONNECTION_ID for every destination CID whose sequence number
is less than retire-prior-to. The CID becomes retired after the
local stack receives an ACK for its RETIRE_CONNECTION_ID frame.
Although the OpenSSL QUIC stack supports at most one destination CID
for every connection, it can be tricked into processing more than
one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC
stack currently retires the destination CID as soon as it receives
the NEW_CONNECTION_ID, while in fact the destination CID must
be retired after an ACK for the RETIRE_CONNECTION_ID frame is received.
Correcting the flawed logic also fixes the backlog growth.
[1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids
FIPS impact: no
The FIPS module is not affected as the QUIC implementation is outside of
the OpenSSL FIPS module boundary.
📍 영향받는 시스템
OpenSSL QUIC 스택을 사용하는 시스템 (버전 미상)
⚔️ 공격 벡터
원격 피어가 NEW_CONNECTION_ID 프레임을 대량으로 전송하고 ACK를 의도적으로 지연시키는 방식
🛡️ 대응 방법
OpenSSL을 최신 보안 패치가 적용된 버전으로 업데이트하여 CID 교체 로직을 수정해야 합니다.
🔧 검증 코드
출력된 OpenSSL 버전을 확인하여 해당 취약점이 해결된 최신 패치 버전인지 확인합니다.