Quicly는 주로 H2O HTTP 서버 내에서 사용하기 위한 IETF QUIC 프로토콜 구현입니다. 8b178e6을 커밋하기 전에 적대적 피어는 추가 흐름 제어 크레딧을 얻기 위해 허용되는 최대 오프셋에서 단 1바이트만 전달하는 STREAM 프레임을 보낼 수 있으며, 이는 특정 상황에서 서비스 거부로 이어질 수 있습니다. 애플리케이션이 순서 없이 도착하는 모든 데이터를 수신되는 최대 오프셋까지 저장하기 위해 수신 버퍼를 준비한다고 가정하면 이 동작은 동일합니다.
Quicly는 주로 H2O HTTP 서버 내에서 사용하기 위한 IETF QUIC 프로토콜 구현입니다. 8b178e6을 커밋하기 전에 적대적 피어는 추가 흐름 제어 크레딧을 얻기 위해 허용되는 최대 오프셋에서 단 1바이트만 전달하는 STREAM 프레임을 보낼 수 있으며, 이는 특정 상황에서 서비스 거부로 이어질 수 있습니다. 애플리케이션이 순서 없이 도착하는 모든 데이터를 수신되는 최대 오프셋까지 저장하기 위해 수신 버퍼를 준비한다고 가정하면, 이 동작으로 인해 피어가 소수의 패킷만 전송하면서 애플리케이션이 많은 양의 메모리를 할당하게 되어 메모리가 소진될 수 있습니다. 수신 버퍼 할당 전략 외에도 이 취약점의 심각도는 애플리케이션이 스트림 동시성을 제어하는 방식에 따라 달라집니다. H2O HTTP 서버의 경우 기본 설정에서 이 버그로 인해 연결당 할당되는 최대 메모리 양이 약 4배 증가합니다. 이 문제는 커밋 8b178e6으로 해결되었습니다.
왜 이 VPI인가 (설명가능 · 실험적)
VPI 산정 기준
| 영향도 | 53.00 |
| 악용 신호(추가 악용신호 없음) | ×1.00 |
| VPI | 53.00 |
VPI 공식 vpi-v1 기준