요약
보안 업체 아이키도 시큐리티가 Node, Python 등에 영향을 주는 원격 코드 실행 취약점 http2shell을 경고했습니다.
아이키도 시큐리티가 X(옛 트위터)에 올린 글을 nitter 미러 주소로 공유한 링크입니다. 제목에 따르면 http2shell은 RCE(원격 코드 실행, 공격자가 남의 시스템에서 임의의 코드를 돌릴 수 있는 취약점)이고, Node와 Python을 비롯한 여러 환경이 영향을 받습니다. 링크가 봇 확인 페이지에 막혀 원문을 읽지 못했습니다.
HN 반응
- 댓글에 따르면 원인은 구글 Brotli 압축 라이브러리 1.2.0 이하의 메모리 버그이고, 2월에 고치고도 1년 가까이 릴리스하지 않은 구글을 탓하는 목소리가 컸습니다.
- 서버는 대개 Brotli 디코더를 기본으로 쓰지 않아 과장됐다는 반론에, Node의 fetch가 br 응답을 자동으로 풀어 서버도 위험할 수 있다는 재반론이 맞섰습니다.
이건 http2shell이 아니라 googlebrotli2shell이라고 불러야 한다고 봐요. 구글은 이번 일로 평판에 타격을 좀 입어도 싸요. 기본적인 메모리 안전성 위반인데, 그걸 낸 곳이 wuffs를 만들고, 메모리 안전을 위해 Rust를 밀고, Carbon까지 가진 바로 그 조직이잖아요. zstd는 고품질 Rust 구현이 있고 나온 시기도 거의 비슷한데요.
게다가 brotli 라이브러리는 거의 1년 가까이 릴리스가 없었고, 이 취약점 수정은 2월에 이미 커밋돼 있었습니다. 구글은 모든 프로젝트를 main에서 빌드하니 영향이 없었겠지만, 오픈소스 릴리스는 완전히 뒷전이에요. 여러 잡다한 수정이 담긴 커밋이 100개 넘게 방치돼 있다가, 보안 사고가 터지고 나서야 마지못해 릴리스가 나왔습니다.
압축 해제 쪽은 그렇습니다. 압축 쪽은 제대로 된 zstd Rust 포팅이 어제서야 발표됐습니다. 그때까지는 Rust에서 zstd보다 brotli가 더 잘 지원되고 있었습니다.
그래도 요즘 압축 해제 라이브러리는 (대부분) 메모리 안전해야 한다는 데는 동의합니다. 그쪽이 구현하기도 더 쉽고 취약해질 가능성도 더 크니까요.
'2shell' 부분을 실제로 보여 준 데모가 있기는 한가요? 이 문제는 멈춤(hang)을 일으킬 수 있다고 보고 고친 것 같던데요. 이게 RCE로 이어질 수 있다고 확인된 적이 있나요? 아니면 아직 가정일 뿐인가요?
Imperva가 시연했다고 주장하지만 공개하지는 않았습니다(그리고 그쪽 글은 AI가 쓴 쓰레기 티가 팍팍 나니 알아서 판단하세요).
https://www.imperva.com/blog/node2shell-from-brotli-data-to-remote-code-execution/
공개된 PoC도 여기 있습니다. 다만 보안 설정이 약한 빌드에서만 시연했다는 단서가 붙습니다. https://github.com/dimasma0305/CVE-2026-111497-POC
그렇긴 해도 대형 클라우드 업체나 보안 연구소가 실제 공격 사례를 봤다고 말한 적은 아직 없습니다.
저장소를 보니 일부 언어는 C 구현을 직접 쓰지 않고 자체 안전 구현을 갖고 있습니다.
다만 테스트가 그리 충실하진 않을 것 같네요.
이번에도 적어도 서버 쪽은 과장된 것 같아요. 방금 200개 넘는 GitHub 저장소가 있는 조직을 점검해 봤어요. Node, Python, C#으로 된 것들인데, 취약한 건 하나도 없었어요. Brotli 디코더를 실제로 호출하는 곳이 없으니까요. 서버 쪽에서는 플랫폼 자체가 기본으로 켜 두지 않거든요. PHP 버그와 비슷해요. 실제로 취약해지려면 특정 조건이 갖춰져야 하죠.
클라이언트는요? 네, 거긴 위험이 더 크죠. 패치하세요. 하지만 공격자는 클라이언트가 자기들한테 접속하지 않는 이상 클라이언트를 공격하지 않아요. 이거 고치겠다고 밤새지 마세요.
(그리고 네, .NET도 여기에 포함돼요. 마이크로소프트의 Brotli 모듈이 구글의 취약한 레퍼런스 구현에 대한 바인딩이거든요.)
Node의 fetch는
br응답이 오면 디코더를 자동으로 호출하지 않나요? 그러면 서버가 fetch하는 공격자 통제 콘텐츠는 뭐든 취약할 수 있는 거 아닌가요?어떻게 확인하셨어요? PoC가 있나요, 아니면 돌려 볼 만한 명령어가 있나요?
쓰시는 Brotli 라이브러리가 2월 커밋보다 오래된 소스로 빌드됐나요? (마지막으로 태그된 릴리스는 그보다 앞서 나왔습니다.)
그렇다면 취약할 수 있습니다.
Brotli를 켜 두지 않았다면 이 취약점에는 해당하지 않습니다.
PHP 건은 이제 익스플로잇이 가능합니다. 특정 조건 같은 건 필요 없어요. 잘못된 정보 좀 그만 퍼뜨리세요.
금요일 기준으로 알려진 침해 사고나 end-to-end 익스플로잇은 없었습니다. 익스플로잇이라고 주장하는 LLM 환각물이나, 주소 유출(address leak) 같은 부분이 빠진 진짜 익스플로잇은 봤지만, 완성된 건 없었어요. 대형 침해 대응 업체(CrowdStrike CAO, Unit 42, Talos)에 있는 지인들도 같은 말을 했고요.
조만간 나오긴 하겠지만, 정황상 이건 무엇보다 프로세스 악몽이었습니다. 또 다른 Log4Shell은 아니었어요.
RCE가 가능하다는 건 수요일에 이미 알려져 있었어요. 자세한 정보는 별로 없었지만요. 사람들은 완화 조치를 취하기 시작했고, 가치 있는 웹사이트를 가진 조직들은 서버를 내리고 있었죠. liveoverflow 채널을 보세요. LLM을 써서 순정 PHP 인스턴스를 공격하는 익스플로잇을 찾는 데 꼬박 하루가 걸렸어요. 간단한 해킹은 아니에요. 하지만 가능합니다.
아니요, 못 찾았어요. 주소 유출이 빠져 있었거든요.
솔직히 메모리 버그마다 귀여운 선정적 이름 붙이고 마케팅 공세까지 하는 건 없었으면 좋겠어요.
허리케인처럼 이름을 붙이면 어떨까요. NIST가 알파벳순 이름 목록을 만들고 CVE 9.0 이상에 이름을 하나씩 배정하는 거죠. 취약점 알렉스(CVE 9.4) 같은 식으로요.
일주일 뒤면 취약점 지직스(Zzyzx)겠네요.
내일이요.
CVE 점수는 이미 부풀려져 있어요. 발견한 사람들 입장에서 그래야 보기 좋으니까요.
"와, 잰(Jan) 때문에 주말 망쳤네."
이런 식이면 꽤 괜찮을 것 같아요.
그 배는 이미 떠난 지 오래입니다. 제가 기억하는 첫 사례는 Rowhammer예요.
Heartbleed도 잊지 말자고요!
이메일 시절에는 바이러스 제작자들이 직접 이름을 붙였죠. YouAreAnIdiot, ILoveYou 같은 거요.
Blaster 바이러스는 재밌는 놈이었죠.
제가 기억하는 최초의 익스플로잇 로고였어요.
저한테 제일 기억에 남는 건 DirtyCOW예요.
Rowhammer는 좀 특별하지 않나요? 물리적 설계 결함에 기반한 거였으니까요.
brotli 1.2.0 이하가 취약한 것 같습니다.
Python 패키지는 이미 1.2.1로 업데이트됐습니다. https://pypi.org/project/brotli/1.2.1/
수정 커밋은 이거예요. https://github.com/google/brotli/commit/b418fa81c48262a86a95332b0bc6d62c30aa78b6
오늘도 C 코드에서 범위를 벗어난 접근이 또 나왔네요.
이 수정의 핵심이 어디인지 짚어 줄 수 있는 분 계세요? 상수 이름 바꾼 것 같은 변경만 잔뜩 보이네요.
제가 이해하기로는 1978번째 줄의
goto saveStateAndReturn;입니다. 이후 처리를 막는 조기 반환이에요.