OpenSSL ‘HollowByte’ 취약점 공개…11바이트로 서버 메모리 고갈

Okta Red Team 공식 분석과 OpenSSL 공식 수정 기록에 따르면, 원격 비인증 공격자가 TLS 연결 초기에 11바이트의 조작된 입력만 보내 서버 메모리를 소진시킬 수 있는 서비스 거부 취약점 ‘HollowByte’가 공개됐다. OpenSSL은 이 문제를 CVE 보안 취약점이 아닌 버그 또는 하드닝 수정으로 처리했다.

TLS 핸드셰이크 메시지는 본문 크기를 알리는 4바이트 헤더로 시작한다. 수정 전 OpenSSL은 상대가 헤더에 적은 크기를 먼저 신뢰해 실제 데이터가 도착하기 전에 수신 버퍼를 늘렸다. 공격자가 큰 메시지가 이어질 것처럼 선언한 뒤 데이터를 보내지 않으면, 서버는 연결 하나당 최대 131KB를 할당한 채 대기하게 된다.

HollowByte의 영향은 연결이 끊어진 뒤에도 이어질 수 있다. OpenSSL이 버퍼를 해제하더라도 GNU C 라이브러리 glibc는 중소 규모 메모리 할당을 운영체제에 곧바로 돌려주지 않는다. 공격자가 서로 다른 크기를 선언한 연결을 반복하면 해제된 공간의 재사용이 어려워지고 힙 단편화가 누적돼 프로세스의 상주 메모리가 계속 커질 수 있다는 설명이다. 이 상태의 메모리를 완전히 회수하려면 프로세스를 종료해야 한다.

Okta는 수정 전후 OpenSSL을 사용한 NGINX 환경에서 영향을 시험했다. 1GB 메모리 환경에서는 단편화된 메모리 547MB가 묶인 시점에 프로세스가 메모리 부족으로 종료됐고, 16GB 환경에서는 전체 메모리의 25%를 점유시키면서도 연결 수 제한 아래에 머물렀다고 밝혔다. 이는 Okta의 통제된 시험 결과이며, 실제 환경의 영향은 서버 구성과 메모리 할당자, 연결 처리 방식에 따라 달라질 수 있다.

OpenSSL은 예상 메시지 전체 크기만큼 버퍼를 한 번에 키우는 대신, 데이터가 실제로 들어올 때 수신 버퍼를 점진적으로 늘리도록 수정했다. 관련 변경은 4월 17일 공식 저장소에 병합됐고 6월 9일 공개된 OpenSSL 4.0.1에 포함됐다. 3.6.3, 3.5.7, 3.4.6, 3.0.21에도 같은 수정이 역이식됐다.

이번 사안은 CVE가 없고 6월 보안 권고 목록에도 별도 항목으로 표시되지 않아 일반적인 취약점 관리 체계에서 놓칠 가능성이 있다. OpenSSL 공식 PR에는 Okta Red Team이 보안 문제를 보고했으며 프로젝트 보안팀이 이를 버그 또는 하드닝 수정으로 다루기로 했다고 명시돼 있다.

OpenSSL은 웹 서버와 언어 런타임, 데이터베이스 등 여러 소프트웨어에 내장된다. 다만 시스템에 OpenSSL이 설치돼 있다는 사실만으로 노출 여부를 단정할 수는 없다. 운영자는 배포판과 제품 공급자가 제공하는 패키지 버전을 확인하고, 내장된 라이브러리까지 수정 버전으로 갱신됐는지 점검할 필요가 있다.

HollowByte는 코드 실행이나 정보 유출이 아니라 서비스 가용성을 겨냥한 문제다. 그럼에도 적은 공격 트래픽으로 메모리 압박을 누적시킬 수 있고 CVE 기반 경보가 제공되지 않는 만큼, 인터넷에 노출된 TLS 서버 운영자는 패키지와 프로세스별 OpenSSL 버전을 우선 확인해야 한다.

출처: Okta Red Team https://sec.okta.com/articles/2026/06/openssl-hollowbtye-a-dos-hiding-in-11-bytes/
OpenSSL 공식 수정 PR https://github.com/openssl/openssl/pull/30792
OpenSSL 공식 릴리스 타임라인 https://openssl-library.org/news/timeline/