🇰🇷 한글 설명
Netty의 기본 토큰 검증 로직 결함으로 인해, 공격자가 위조된 소스 IP를 사용하여 초기 패킷에 임의의 토큰을 포함하면 서버가 클라이언트 주소를 유효한 것으로 오인합니다. 이로 인해 RFC 9000의 증폭 제한이 해제되어 서버가 제한 없이 대규모 데이터(인증서 등)를 위조된 IP로 전송하는 증폭 공격이 가능합니다.
💡 쉬운 설명
서버가 클라이언트의 주소를 확인하는 과정에서 결함이 있어, 공격자가 가짜 주소를 사용하여 서버가 과도한 데이터를 보내도록 유도할 수 있습니다. 이 취약점을 이용하면 공격자는 작은 패킷으로 큰 데이터를 보내는 증폭 공격을 수행할 수 있습니다.
🇺🇸 원문 (English)
Netty is a network application framework for development of protocol servers and clients. NoQuicTokenHandler is the tokenHandler used when the application does not set one. Prior to version 4.2.15.Final, its writeToken() returns false (server will not send Retry — acceptable), but validateToken() unconditionally `return 0`. In QuicheQuicServerCodec.handlePacket(), a non-negative return from validateToken() is interpreted as 'token is valid, ODCID starts at offset 0', causing the server to call quiche_accept as if the client's address had been validated by a Retry round-trip. Per RFC 9000 §8.1, a validated address lifts the 3× anti-amplification send limit. Thus any attacker who includes ANY non-empty token bytes in an Initial packet — with a spoofed victim source IP — causes the Netty server to treat the victim as validated and reflect full-size handshake flights (certificates, etc.) toward it without the 3× cap. The correct 'no token handler' semantics would be to return -1 (invalid) so the normal un-validated path and amplification limit apply. Version 4.2.15.Final patches the issue.
📍 영향받는 시스템
Netty 4.2.15.Final 미만 버전
⚔️ 공격 벡터
위조된 소스 IP를 사용한 초기 패킷에 임의의 토큰을 포함하여 서버의 주소 검증 로직을 우회
🛡️ 대응 방법
Netty를 4.2.15.Final 이상으로 업그레이드하여 패치된 버전으로 교체
🔧 검증 코드
출력된 버전 번호가 4.2.15.Final보다 작은 경우 취약한 버전이므로 업그레이드가 필요합니다.
mvn dependency:tree -Dincludes=io.netty:netty-all 2>/dev/null | grep -E 'io.netty:netty-all:[0-9]+\.[0-9]+\.[0-9]+\.Final'