OpenAI, Slack, Meta, GitHub 밑에는 같은 이미지 라이브러리가 있다. 그것을 뚫는 데 걸린 시간은 모델의 세 시간이었다

Hacktron의 연구자 세 명은 이번 여름 내내 실 한 가닥을 잡아당겼다. HEIC, HEIF, AVIF 파일을 픽셀로 바꾸는 오픈소스 C 라이브러리 libheif다. 이번 주 그들은 그 실 끝에 무엇이 있었는지를 공개했다. 이 라이브러리의 디코딩 경로에 있는 힙 버퍼 오버플로를 통해 연구진은 OpenAI 커뮤니티 포럼에서 원격 코드 실행을 얻었고, 거기서 OpenAI 직원들의 ChatGPT 및 Codex 계정으로, 다시 그 계정에 연결된 GitHub 저장소로 도달했다. 같은 유형의 결함은 Slack, Meta, GitHub Enterprise Server, Discourse, Next.js에도 미쳤다.

모두 패치되었다. 이 글의 요점은 버그 자체가 아니다.

아무도 적어두지 않는 의존성

사용자가 올린 사진을 받는 플랫폼은 거의 예외 없이 그것을 디코딩해야 하지만, 직접 디코딩하는 곳은 거의 없다. 바이트는 네이티브 라이브러리로 넘어가고, HEIC와 AVIF의 경우 그 라이브러리는 대개 libheif이며, 실제 HEVC 디코딩은 다시 libde265에 맡겨진다. 제품 소개 페이지에 이름이 실리는 일은 없고, 위협 모델에 등장하는 경우도 드물며, 대부분의 스택에서는 이미지 처리 라이브러리나 썸네일 서비스를 거쳐 서너 겹 아래에 딸려 들어온다.

업스트림 권고문 GHSA-g89c-p67h-r497은 심각도를 9.8로 평가하며 조건을 명료하게 서술한다. 조작된 HEIC, HEIF, AVIF 파일이 평범한 디코딩 호출 과정에서 힙 버퍼 오버플로를 일으킨다. 인증도, 사용자 상호작용도, 특수한 API 설정도 필요하지 않다. 신뢰할 수 없는 이미지를 디코딩하는 모든 애플리케이션이 대상이다. 이 권고문에는 고유한 CVE가 할당되어 있지 않다. "CVE가 있다"는 사실이 "추적되고 있다"의 대용이 될 수 없음을 상기시키는 대목이다.

영향 목록이 한 벤더의 고객 명단이 아니라 현대 웹의 주소록처럼 읽히는 이유가 여기에 있다.

무엇을 패치해야 하나

이 목록에 있는 것을 직접 운영하고 있다면 할 일은 버전 번호가 전부다. 자체 이미지 파이프라인을 운영한다면 물어야 할 것은, 어떤 서비스가 모르는 사이에 libheif를 호출하고 있는지, 그리고 그 디코딩이 샌드박스 안에서 일어나는지 아니면 애플리케이션 프로세스 안에서 일어나는지다.

14시간, 그리고 6,500달러

연구진 보고서에 담긴 OpenAI 관련 타임라인은 이례적으로 구체적이다. 7월 23~24일, Discourse를 통해 도달 가능한 libheif에서 오버플로를 찾아냈다. 7월 25일 아침에는 community.openai.com에서 코드 실행을 확보했다. 몇 시간 안에 OpenAI의 Bugcrowd 프로그램을 통해 신고했고, 이어 직원 계정을 탈취하고 OpenAI 내부 코드베이스에 풀 리퀘스트를 열어 영향을 입증했다. OpenAI는 같은 날 22시 49분 UTC에 수정을 확인했다. 신고로부터 14시간이 채 걸리지 않았다. Discourse 업스트림과 조율했고, 9월 1일 6,500달러의 포상금을 지급했다.

이 대응이야말로 이 사건에서 제대로 작동한 부분이다. 포럼은 아무도 프로덕션으로 여기지 않기 때문에 오히려 실질적인 접근 권한이 쌓이는 전형적인 "격이 낮은 인접 자산"이다. OpenAI는 그것을 프로덕션으로 취급했다.

중요한 것은 세 시간

이미지 파서의 메모리 손상 버그는 새로운 것이 아니다. 퍼징은 20년 동안 이런 결함을 찾아내 왔다. 지금까지 이를 제약해 온 것은, 크래시를 찾는 일은 값싸지만 그 크래시를 방어가 강화된 현대적 표적에 대해 안정적으로 동작하는 익스플로잇으로 만드는 일은 비싸고 희소한 전문성을 요구한다는 사실이었다. 이 간극이 있었기에 이런 종류의 버그는 대부분 조용히 수정되고 무기화되지 않았다.

연구진은 그 간극이 사라졌다고 말한다. 그들의 설명에 따르면 Claude Opus 4.8은 표준 메모리 보호가 켜진 상태에서 동작하는 익스플로잇을 여러 세션에 걸쳐 만들어내지 못했다. 출시 몇 시간 만에 Opus 5에 같은 문제를 주자 약 세 시간 만에 성공했고, 연구진은 그것을 표적이 돌아가는 아키텍처로 이식했다. 프로젝트 페이지는 프런티어 모델을 쓴 에이전트 방식이 첫 탐색부터 원격 코드 실행까지의 익스플로잇 개발 기간을 대략 1~3일로 압축했다고 설명한다.

결론은 그들 자신의 문장에 있다.

AI는 이 희소한 전문성을 점점 더 많이 연산으로 바꿔놓음으로써 그 보호막을 걷어내고 있다. 한때 자원이 넉넉한 팀과 수개월의 노력을 요구하던 작업이 이제 며칠로 압축될 수 있다.

이는 연구진이 자신들의 도구에 대해 내놓은 주장이며, 그렇게 읽혀야 한다. 다만 뒷받침하는 근거는 수사가 아니다. 일곱 개 플랫폼의 수정, GitHub의 CVE 발급, 지급된 포상금, 그리고 입증된 영향과 함께 도착한 신고 덕분에 하루가 채 되기 전에 배포된 패치가 그것이다.

방어자가 가져가야 할 것

실무적 교훈은 AI에 관한 것이 전혀 아니다. 패치되지 않은 의존성의 경제학이 달라졌다는 것이다. 자사가 배포하고 있는 줄도 몰랐던 파서의 메모리 안전성 버그는 지금까지 긴 목록에 놓인 이론적 위험이었다. "아무도 굳이 무기화하지 않을 것"이라는 전제는 이제 그 논리의 가장 약한 고리이며, 대부분의 백로그 분류가 조용히 기대고 있는 전제이기도 하다.

libheif를 1.23.2로 올려라. 그런 다음 스택에서 신뢰할 수 없는 바이트를 C로 파싱하는 다른 무엇이 있는지, 그리고 그 일이 격리 가능한 곳에서 일어나고 있는지 확인하라.

출처: Hacktron: Hacking OpenAI · HEIF Heist · libheif 권고문 GHSA-g89c-p67h-r497 · Forbes: Security Researchers Hacked Into OpenAI Using Anthropic's Claude