진화하는 위협: Node, Python 등에서 원격 코드 실행을 일으키는 http2shell

Hacker News 의견들 이름을 http2shell이 아니라 googlebrotli2shell로 붙여야 한다고 봄. Google도 평판에 타격을 좀 받아야 함. wuffs를 만들고, 메모리 안전성을 위해 Rust를 장려하고, Carbon까지 보유한 조직에서 나온 기본적인 메모리 안전성 위반임. 비슷한 시기에 나온 zstd에는 고품질 Rust 구현도 있음. 게다가 Brotli 라이브러리는 거의 1년 동안 릴리스가 없었고, 이번 취약점 수정은 이미 2월에 커밋됐음. Google은 모든 프로젝트를 main에서 빌드하니 영향을 받지 않았지만, 오픈소스 릴리스는 뒷전임. 각종 수정 커밋 100개 이상을 묵혀 두다가 보안 사고가 터져야 릴리스하는 셈임. 압축 해제 쪽은 맞지만, 제대로 된 첫 zstd Rust 압축 구현은 어제 발표됐음. 그전까지 Rust 지원은 zstd보다 Brotli가 나았음. 그래도 요즘 압축 해제 라이브러리는 대부분 메모리 안전해야 한다는 데 동의함. 압축 해제 쪽이 구현도 쉽고 취약점에 노출될 가능성도 더 크기 때문임. 메모리 버그마다 귀엽고 자극적인 이름을 붙여 마케팅까지 하는 건 그만 봤으면 함. 허리케인처럼 이름을 붙이면 어떨까? NIST가 알파벳순 이름 목록을 만들고 CVE 점수 9.0 이상에 이름을 배정하는 식임. 예를 들면 ‘취약점 Alex, CVE 9.4’임. 이미 오래전에 그렇게 굳어졌음. 내가 기억하는 첫 사례는 Rowhammer임. 적어도 서버에서는 이번에도 위험이 과장된 듯함. Node, Python, C#을 쓰는 조직의 GitHub 저장소 200개 이상을 확인했는데 취약한 곳은 없었음. 실제로 Brotli 디코더를 호출하는 곳이 없었기 때문임. 해당 플랫폼들은 서버 측에서 이를 기본 활성화하지 않음. 특정 조건이 충족돼야 취약해지는 PHP 버그와 비슷함. 클라이언트는 위험이 더 크니 패치해야 함. 하지만 클라이언트가 공격자에게 접속하지 않는 한 공격받지는 않으니, 밤을 새워 고칠 일은 아니라고 봄. .NET도 해당됨. Microsoft의 Brotli 모듈은 Google의 취약한 참조 구현을 감싼 바인딩이기 때문임. Node의 fetch 는 br 응답에 자동으로 디코더를 호출하지 않나? 그렇다면 서버가 가져오는 콘텐츠를 공격자가 통제할 수 있을 때 취약해질 수 있지 않나? 어떻게 확인했나? 실행할 수 있는 PoC나 명령어가 있나? PHP 취약점은 이미 악용 가능함. 특별한 ...