AI 생성서버에 OpenSSL 쓴다면 꼭 확인 — CVE 번호도 없이 11바이트로 서버가 멈추는 ‘홀로우바이트’

🤖 AI 생성 콘텐츠 — 이 글은 AI가 자료를 수집하고 초안을 작성했으며, 발행 전 누슘 운영자가 검수했습니다.

Okta 레드팀이 OpenSSL에서 단 11바이트의 TLS 요청만으로 서버 메모리를 고갈시킬 수 있는 결함 ‘홀로우바이트(HollowByte)’를 발견했다. 그런데 이 결함엔 CVE 번호도, 보안 권고문도 없다.

인증조차 필요 없다. 공격자가 서버에 보내는 데이터는 딱 11바이트면 충분하다. 그것만으로 OpenSSL을 쓰는 서버의 메모리를 조금씩 고갈시켜 결국 서비스를 마비시킬 수 있는 결함이 발견됐다. 보안 업계는 이를 홀로우바이트(HollowByte)라 부르고 있다. 더 이례적인 건, 이 정도 파급력을 가진 결함인데도 정식 CVE 번호나 별도 보안 권고문이 발급되지 않았다는 점이다.

목차

• 홀로우바이트는 정확히 어떻게 동작하나
• 왜 CVE 번호가 없나
• 지금 뭘 해야 하나

홀로우바이트는 정확히 어떻게 동작하나

이 결함을 발견한 곳은 Okta 레드팀이다. 이들이 주목한 지점은 TLS 핸드셰이크 메시지의 구조였다. TLS 핸드셰이크 메시지는 4바이트짜리 헤더로 시작하는데, 이 중 3바이트가 “본문(body)이 얼마나 긴지”를 미리 선언하는 역할을 한다.

문제는 취약한 버전의 OpenSSL이 이 선언값을 그대로 믿어버린다는 데 있었다. 헤더만 도착한 순간, 아직 본문 데이터는 단 한 바이트도 오지 않았고 핸드셰이크 자체의 유효성 검증도 실행되기 전인데, OpenSSL이 곧바로 그 선언된 크기만큼 수신 버퍼를 미리 할당해버린 것이다.

즉 공격자는 실제로는 데이터를 거의 보내지 않으면서 “이만큼 큰 본문이 온다”고 선언만 반복하면, 서버는 매번 그 선언값만큼 메모리를 미리 잡아둔다. 이 요청을 여러 번 반복하면 서버 메모리가 조금씩 비어가다가 결국 소진되어 서비스 거부(DoS) 상태에 빠진다.

왜 CVE 번호가 없나

보통 이 정도 파급력의 원격 무인증 DoS 결함이라면 CVE 번호와 보안 권고문이 따라붙는 게 일반적이다. 그런데 OpenSSL 프로젝트는 이번 수정을 보안 취약점이 아니라 버그 또는 견고성(hardening) 개선으로 분류했다. 그 결과 CVE 식별자도, 전용 보안 권고문도, 배포판 변경 로그의 명시적 언급도 없이 조용히 패치만 반영됐다.

이 판단 방식이 논쟁적인 이유는 분명하다. CVE가 없으면 많은 조직의 취약점 관리 프로세스에서 이 이슈가 아예 스캔 대상에서 빠질 수 있다. “고쳤으니 됐다”가 아니라 “고쳤는데 아무도 그 사실을 자동으로 알기 어렵다”는 게 진짜 문제인 셈이다.

지금 뭘 해야 하나

수정된 버전은 이미 공개돼 있다. OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6, 3.0.21 — 모두 6월 9일자로 배포됐다. CVE 추적이나 자동 취약점 스캐너에 의존해온 조직이라면, 이번 건은 그 방식만으로는 놓칠 수 있으니 배포판·의존성 매니저의 OpenSSL 버전을 버전 번호 기준으로 직접 확인하는 게 안전하다.

특히 TLS를 직접 종단(terminate)하는 리버스 프록시, 로드밸런서, 임베디드 기기처럼 OpenSSL을 오래된 버전 그대로 박아두는 경우가 많은 인프라는 우선순위를 높여 점검할 필요가 있다.

자주 묻는 질문 (FAQ)

Q. 홀로우바이트 공격을 실행하는 데 특별한 권한이 필요한가? A. 아니다. 인증 없이 TLS 연결을 시도할 수 있는 누구나 시도할 수 있는 무인증 공격이다.

Q. CVE 번호가 없는데 왜 이렇게 주목받나? A. 단 11바이트로 서버 메모리를 고갈시킬 수 있는 파급력과, CVE 없이 조용히 패치된 점이 취약점 관리 관점에서 이례적이기 때문이다.

Q. 어떤 OpenSSL 버전이 안전한가? A. 4.0.1, 3.6.3, 3.5.7, 3.4.6, 3.0.21 버전(모두 6월 9일자 배포) 이상이면 이번 결함이 패치돼 있다.

Q. 이 결함을 누가 발견했나? A. Okta의 레드팀이 TLS 핸드셰이크 메시지의 버퍼 할당 로직을 분석하다 발견했다.

Q. 패치를 적용하면 끝인가? A. 패치 적용이 핵심 대응이지만, CVE로 추적되지 않으므로 자동 스캐너만 믿지 말고 실제 OpenSSL 버전 번호를 직접 확인하는 절차를 병행해야 한다.

마치며

CVE 번호가 없다고 위험하지 않은 게 아니라는 걸 보여주는 사례다. 취약점 관리를 CVE 목록에만 의존하고 있다면, 홀로우바이트 같은 사례가 새어나갈 틈이 된다. 혹시 이번 패치를 이미 적용해본 분이 있다면 버전 확인 과정에서 겪은 이슈를 댓글로 공유해주시면 좋겠다.

참고자료

• The Hacker News — OpenSSL ‘HollowByte’ flaw could freeze servers

태그: #OpenSSL #HollowByte #TLS보안 #DoS공격 #메모리고갈 #웹보안 #CVE #Okta레드팀 #오픈소스보안