Node.js를 넘어선 Brotli 취약점, 어디까지 점검하고 디코딩은 끌 수 있나
Node.js의 런타임 업데이트로 드러난 Brotli 디코더 결함은 같은 C 코드를 포함한 Python 패키지에도 영향을 줍니다. 각 환경의 입력 경로와 수정 버전, Brotli 디코딩을 끄는 선택지를 살펴보되, 기능 비활성화가 패치를 대체하는지는 구분해야 합니다.
Bye Bye Brotli? Google's Compression Library Is a Security Mess
브로틀리와 작별할 때인가? 구글 압축 라이브러리의 보안 난맥상
Bugsink 개발자는 Brotli의 메모리 손상과 압축 해제 폭탄 취약점뿐 아니라, 수정 사항의 늦은 릴리스와 불충분한 문서화를 문제 삼습니다. Bugsink에서는 Brotli 디코딩을 끄는 기능을 추가하고, Brotli 지원 자체가 필요한지 검토하겠다고 밝혔습니다.
- 주제
에디터 노트
가장 설득력 있는 비판은 취약점이 발견됐다는 사실보다 수정 사항이 릴리스와 문서로 이어지는 데 걸린 시간입니다. 작성자가 제시한 이전 사례에서는 공개 수정부터 Python 패키지 배포까지 414일이 걸렸고 사용법 문서도 빠져 있었습니다. urllib3가 제한 기능을 구현한 뒤 다시 취약점을 수정한 사례는 문서와 인터페이스가 보안 조치의 일부라는 점을 구체적으로 보여줍니다. 다만 글은 Brotli 전체를 지원 중단할지 묻는 의견이며, 어떤 배포 환경에서 취약한 코드가 실제로 악용됐는지나 대체 구현이 충분한지는 제시하지 않습니다. Reddit에서 구글이 방치했다는 해석이 나오자 원글 작성자는 수정 자체는 이뤄졌고 공개되지 않았다고 바로잡았습니다. 따라서 댓글의 무관심 추측보다 릴리스 지연과 관리 자원 부족이 확인 가능한 쟁점입니다.
AI 요약
Bugsink 개발자는 Brotli 디코더의 취약점과 프로젝트의 보안 대응·배포 과정을 비판하며, 사용처에 따라 Brotli 지원을 중단할지 검토하자고 제안합니다.
HTTP2Shell과 Brotli 디코더
글은 Node2Shell로 알려졌던 취약점의 실제 원인이 Brotli 디코더에 있다며 HTTP2Shell 대신 Brotli2Shell이라 부르자고 주장합니다. 악의적으로 만든 Brotli 데이터를 디코딩할 때 메모리 손상이 발생할 수 있으며, 웹 서버처럼 신뢰할 수 없는 입력을 디코딩하는 환경에서는 위험하다고 설명합니다. 작성자에 따르면 구글은 2026년 2월 27일 수정 사항을 반영했지만, 보안 문제로 보지 않아 Brotli 릴리스가 나올 때까지 공개되지 않았습니다. 정기 릴리스 일정이 사실상 관리자가 시간을 낼 때였고, 새 버전은 10월 21일에야 나왔습니다. Node의 보안 권고가 Brotli 릴리스보다 먼저 공개돼 다른 사용자가 영향과 대응을 파악해야 했다는 점도 지적합니다.
압축 해제 폭탄 수정의 지연
작성자는 2025년에도 Python용 Brotli의 압축 해제 폭탄 문제를 만났다고 합니다. 작은 입력이 메모리에서 크게 팽창해 메모리 고갈 서비스 거부 공격을 일으킬 수 있었고, Bugsink는 Content-Encoding: br 요청을 자동으로 디코딩해 취약한 상태였습니다. 당시 업데이트는 출력 크기를 제한할 매개변수를 추가했지만, 사용법 문서가 없었습니다. urllib3는 2025년 12월 5일 제한 기능을 구현한 뒤, 153일 후 그 구현이 또 다른 심각한 압축 해제 폭탄 취약점을 만들었다며 수정했습니다.
이전 수정의 공개 일정도 늦었습니다. 수정 사항은 2024년 9월 17일 공개 저장소에 처음 반영됐고, 2025년 1월 8일 병합됐습니다. 9일 뒤 보안 수정이라는 설명이 담긴 릴리스 노트가 작성됐지만 C 라이브러리 릴리스는 2025년 10월 27일에야 나왔습니다. Python 패키지는 다시 9일을 기다렸습니다. 작성자가 정리한 경과는 최초 공개부터 병합까지 113일, 릴리스 노트까지 122일, C 라이브러리 태그까지 405일, Python 패키지 배포까지 414일입니다. 실제 사용법 문서는 글 작성 시점에도 나오지 않았다고 합니다.
저장소 상태와 대응 방안
작성자는 공개된 GitHub 저장소의 미해결 PR에 경계 밖 읽기 세 건이 있고, 릴리스 노트 누락이나 다음 배포 일정에 관한 불만도 있다고 적습니다. 관리자는 시간이 날 때 릴리스한다며 자원 부족을 언급했다고 합니다. .NET 구현에는 CPU를 소진시키는 문제가 1년 넘게 있었고, 구글이 공식 NuGet 패키지를 배포하지 않아 널리 쓰이지 않을 수 있지만 코드를 복사해 사용하는 사례는 있다고 덧붙입니다.
Bugsink는 Sentry SDK 호환 오류 추적기라 Python SDK가 보내는 Brotli 데이터를 처리해야 합니다. 작성자는 실제로 Brotli를 보내지 않는 자체 호스팅 사용자가 향후 RCE 위험을 피하도록 디코딩을 끄는 기능을 추가하고, Sentry에도 Brotli 지원을 없앨 수 있는지 문의했다고 밝혔습니다. 더 관리가 잘되는 Rust 구현을 Python 래퍼로 연결하는 방안도 언급하지만, 당장 실제 코드로 채택할 준비가 된 아이디어는 아니라고 선을 긋습니다. 다른 사용자에게는 Brotli 지원이 정말 필요한지 검토하자고 제안합니다.
Reddit 반응
- @SleeperAwakened — 구글이 프로젝트를 끝내 온 전력을 생각하면 Brotli도 오래전에 버렸을 줄 알았습니다. 구글이 Brotli를 신경 쓰지 않게 됐는데 우리만 그 소식을 못 들은 것 같네요.
- @klaasvanschelven — 맞습니다. 구글은 Brotli를 버렸는데, 그 작업을 하던 한 사람에게 그만두라고 말하는 것만 잊었습니다.
- @ParanoidSuricata — 이 정도면 음모론자들이 NSA 같은 곳을 의심할 법한데, 아무도 그러지 않는 게 놀랍습니다.
- @klaasvanschelven — 실제 전문 조직이 이렇게 방치하는 건 오랜 기간 공들인 음모치고는 좀 그렇겠네요.
- @ParanoidSuricata — 솔직히 가능하다고 봅니다. 구글 사업에 중요한가요? 아니죠. 충분히 작동해서 모두가 채택했나요? 그렇습니다. 그러니 취약점을 찾는 일은 구글 우선순위에서 한참 밀렸고, 수년 동안 손도 대지 않았을 수 있습니다. PHP2Shell도 보세요.
- @klaasvanschelven — 문제는 수정은 했는데 릴리스하지 않았다는 겁니다.
- @ParanoidSuricata — 젠장. 출처가 있나요? 구글 검색은 아무것도 못 찾네요.
- @klaasvanschelven — 원글이 출처 아닌가요?
- @RealPropRandy — 걱정 마세요. 대충 생성한 코드가 바로 고쳐줄 테니까요.
원문: Bugsink / 번역·요약: Trawling