▲

MongoBleed 취약점에 대한 간단 설명

 (bigdata.2minutestreaming.com)
2P by GN⁺ 9일전 | ★ favorite | 댓글 1개
  • MongoBleed(CVE-2025-14847) 은 2017년 이후 모든 MongoDB 버전에 존재한 심각한 메모리 누출 취약점으로, 공격자가 데이터베이스의 힙 메모리 임의 데이터를 읽을 수 있음
  • 취약점은 zlib 압축 경로의 버그로 인해 발생하며, 인증 없이 단순히 데이터베이스에 연결만 해도 악용 가능
  • 공격자는 조작된 압축 요청을 보내 서버가 잘못된 크기의 버퍼를 할당하도록 유도하고, 그 안의 이전 작업 메모리(비밀번호, API 키 등) 를 노출시킬 수 있음
  • MongoDB는 2025년 12월 19일 패치를 배포했으나, EOL 버전(3.6, 4.0, 4.2) 은 수정되지 않음
  • 8년간 존재한 이 취약점은 인터넷에 노출된 21만 개 이상 MongoDB 인스턴스에 영향을 주며, 클라우드·온프레미스 환경 모두에서 즉각적 패치 또는 압축 비활성화가 필요함

MongoBleed 개요

  • MongoBleed(CVE-2025-14847) 은 MongoDB의 zlib 1 메시지 압축 경로에서 발견된 취약점으로, 2017년 이후 모든 버전에 영향을 미침
    • 공격자는 인증 없이 데이터베이스에 연결만 하면 임의의 힙 메모리 데이터를 읽을 수 있음
    • MongoDB 3.6, 4.0, 4.2 등 지원 종료(EOL) 버전은 수정되지 않음
  • 이 버그는 2017년 5월의 PR에서 도입되었으며, 2025년 12월 19일 공식적으로 공개됨
  • MongoDB는 Atlas 클라우드 서비스를 포함한 모든 인스턴스에 패치를 적용했다고 발표

MongoDB 통신 구조

  • MongoDB는 HTTP 대신 자체 TCP 프로토콜을 사용하며, 메시지는 BSON(Binary JSON) 형식으로 전송됨
  • 모든 요청은 OP_MSG 명령으로 구성되며, 압축 시 OP_COMPRESSED 메시지로 감싸짐
    • 메시지에는 uncompressedSize, originalOpcode, compressorId 등의 필드가 포함됨
    • uncompressedSize는 압축 해제 후의 예상 크기를 나타냄

익스플로잇 단계 1 — 잘못된 버퍼 할당

  • 공격자는 uncompressedSize 값을 실제보다 과도하게 큰 값으로 설정해 서버가 큰 버퍼를 할당하도록 만듦
    • 예: 실제 1KB 메시지를 1MB로 선언
  • MongoDB 서버는 압축 해제 후 실제 크기를 검증하지 않고 사용자가 지정한 크기를 신뢰함
    • 결과적으로 메모리에는 [실제 데이터 | 미참조 힙 쓰레기] 형태의 구조가 남음
  • C++ 기반 MongoDB는 메모리 초기화를 수행하지 않기 때문에, 이 영역에는 이전 작업의 민감 데이터가 포함될 수 있음
    • 예: 비밀번호, 세션 토큰, API 키, 고객 데이터, 시스템 설정 등

익스플로잇 단계 2 — 데이터 유출

  • 공격자는 잘못된 BSON 입력을 전송해 서버가 메모리의 쓰레기 데이터를 문자열로 파싱하도록 유도
    • BSON의 첫 필드는 문자열이며, C 언어의 널 종료 문자열(null-terminated string) 규칙을 따름
  • 공격자가 널 종료 문자가 없는 문자열을 보내면, 서버는 메모리 내 다른 데이터까지 읽어들임
    • 예시: [ { "a | password: 123\0 | apiKey: jA2sa | ip: 219.117.127.202 ]
  • 서버는 이를 잘못된 BSON 필드로 인식하고 오류 메시지에 해당 내용을 포함해 응답
    • "errmsg": "invalid BSON field name 'a | password: 123'"
  • 이 과정을 반복하면 공격자는 힙 메모리 전체를 스캔하며 민감 정보를 수집 가능

영향 및 위험성

  • 인증 전(pre-auth) 단계에서 발생하므로, 공격자는 로그인 없이 데이터에 접근 가능
  • 인터넷에 노출된 MongoDB 인스턴스는 즉시 위험에 노출됨
    • Shodan 검색 기준 213,000개 이상의 MongoDB 인스턴스가 공개 상태
  • 2017년부터 2025년까지 약 8년간 존재한 취약점으로, 단순한 구조 탓에 실제 악용 가능성이 높음
  • MongoDB는 “현재까지 악용 증거는 없다”고 밝혔으나, 공식 사과나 상세 타임라인은 공개하지 않음

완화 방법

  • 최신 패치 버전(8.0.17 이상) 으로 업데이트
  • 단기적으로는 zlib 네트워크 압축 비활성화로도 완화 가능
  • MongoDB Atlas 사용자는 이미 패치 적용 완료

추가 정보 및 관련 논의

요약

  • MongoBleed는 zlib 압축 처리 버그로 인해 발생한 메모리 누출 취약점
  • 공격자는 조작된 압축 요청을 통해 이전 메모리 데이터(비밀번호, API 키 등) 를 획득 가능
  • 2017~2025년 모든 MongoDB 버전이 영향받으며, 패치 또는 압축 비활성화가 필수
  • 인터넷 노출 인스턴스 21만 개 이상이 잠재적 피해 대상
  • MongoDB는 패치를 배포했으나, EOL 버전 미지원 및 공개 대응 지연이 지적됨
▲
GN⁺ 9일전  [-]
Hacker News 의견들
  • 몇 년 전 나는 Cloudflare Workers 런타임의 메모리 할당기(memory allocator) 를 수정해, 해제 시 모든 메모리를 고정된 바이트 패턴으로 덮어쓰도록 했음
    덕분에 초기화되지 않은 메모리에는 의미 있는 데이터가 남지 않게 되었음
    성능 저하를 예상했지만 실제로는 측정 가능한 영향이 전혀 없었음
    메모리 안전하지 않은 언어를 쓰는 사람이라면 모두 이렇게 해야 한다고 생각함. 이번 Mongo 버그도 이런 방식으로 완화할 수 있었을 것임
    • 최신 macOS는 메모리 해제 시 자동으로 zero-out을 수행함
      이 덕분에 메모리 압축 효율이 높아지고, 평균적으로는 오히려 성능이 향상된다고 함
    • FreeBSD에서는 MALLOC_CONF=opt.junk=free 환경 변수를 설정하면 malloc이 같은 동작을 수행함
      즉, 이미 많은 구현체가 이런 기능을 옵션으로 제공하고 있음
    • 2025년에는 모든 일반 할당기가 기본적으로 메모리를 0으로 초기화해야 한다고 생각함
      성능이 더 필요하면 특정 용도에 맞게 커스텀 할당기를 작성하면 됨
      시스템 할당기에서는 불가능한 다른 최적화도 가능해질 것임
    • OpenBSD는 새로 할당된 메모리를 0xdb, 해제된 메모리를 0xdf로 채움
      덕분에 use-before-initialization이나 use-after-free 버그를 빠르게 잡을 수 있음
      이게 기본 설정으로 되어 있음
    • 혹시 이게 커널의 init_on_free=1 옵션을 켜는 것과 같은 동작인지 궁금함
  • 글쓴이가 Mongo의 내부 개발 프로세스를 잘 몰랐던 것 같음
    Mongo는 내부 비공개 저장소에서 개발 후, Copybara를 통해 공개 저장소로 커밋을 옮김
    날짜 혼란은 이 과정에서 생긴 것임
    • 나도 몰랐음. PR 리뷰가 없다는 점이 이상하다고 생각했는데 이제 이해됨
      글을 업데이트해서 이 사실과 날짜 차이를 설명할 예정임
  • 글쓴이가 타임라인을 잘못 이해한 듯함
    우리 Atlas 클러스터는 CVE가 발표되기 며칠 전에 이미 업그레이드가 완료되었음
    • 고마움. 글을 업데이트했음
  • 데이터베이스 같은 시스템에서는 메모리 해제 시 zeroing 또는 poisoning을 하는 게 좋은 선택임
    요즘은 대부분의 할당기가 기본적으로 그렇게 해야 함
    Blink에서 Chris가 이 부분을 개선했고, 그 결과가 Chromium 전체로 확산되었음
    관련 문서도 흥미로움
    Chromium 블로그 글
    PartitionAlloc 문서
  • Mongo 인스턴스가 인터넷에 얼마나 자주 노출되는지 궁금함
    SQL 쪽에서는 드물지만 가끔 있긴 함
    • 내 경험상 MongoDB의 존재 이유는 “게으름” 임
      스키마, 내구성, 읽기/쓰기, 연결성 등 아무것도 신경 쓰지 않아도 된다는 철학임
      그래서 보안도 신경 쓰지 않는 게 놀랍지 않음
    • 내가 아는 “진지한” 조직 3곳 모두 Mongo를 쓰는 이유가 스키마 설계를 피하기 위해서였음
      이런 태도는 “지금 당장 편하자”는 생각으로 이어지고, 결국 공개 DB 인스턴스 같은 보안 문제로 연결됨
    • 이런 의견들 너무 극단적인 것 같음
      실제로는 SQL과 NoSQL을 함께 사용하는 게 일반적임
      NoSQL은 대규모 데이터의 고가용성에 강점이 있고, SQL은 관계형 데이터 저장에 적합함
      예를 들어 iMessage나 EA의 매치메이킹 시스템도 NoSQL을 사용함
      결국 둘 다 필요함. 경쟁 관계가 아니라 보완 관계임
    • Shodan 검색 결과에 따르면 21만 3천 개의 Mongo 인스턴스가 노출되어 있음
    • SQL 서버를 노출하면 더 심각한 결과가 생김
      예를 들어 PostgreSQL은 기본 설정만으로도 시스템 전체 권한을 가질 수 있음
      그래서 대부분의 사람들은 공개 SQL 서버의 위험성을 잘 알고 있음
  • MongoDB가 12월 24일에 “CVE 악용 증거가 없다”고 발표했는데, “증거가 없다는 건 존재하지 않는다는 증거가 아니다” 라는 점을 잊지 말아야 함
    • 그렇다면 그들이 뭐라고 말했어야 한다고 생각함?
  • 왜 아직도 Mongo를 쓰는지 이해가 안 됨
    • 복제(replication) 가 쉽고, Postgres의 JSONB보다 빠름
      개인적으로는 쓰고 싶지 않지만, DynamoDB나 MongoDB가 기술적으로 적합한 경우도 있음
    • “web scale”이라서 쓴다는 농담도 있음
      관련 영상
    • 예전에는 NoSQL이 유행이었지만, 결국 단순한 key-value DB로 귀결되었음
    • 이건 너무 공격적인 논리라 받아들이기 어려움
  • OWASP Top 10이 주요 취약점을 해결할 거라는 낙관론을 떠올리게 됨
    하지만 버퍼 오버플로우는 2003년부터 여전히 존재함
    • 결국 footgun을 모두에게 쥐여준 셈임
      이런 문제는 언어 차원에서 막지 않는 한 영원히 반복될 것임
      Mongo 개발자들에게 위로를 보냄
  • NoSQL 관련 글이 올라올 때마다, 많은 “개발자들”이 대규모 트래픽을 다뤄본 적이 없다는 사실이 드러남
    • 이번엔 그냥 너 혼자 그런 것 같음
  • MongoDB는 항상 별로였음… 하지만 “webscale”이라 불림
    차라리 ToroDB나 PostgreSQL의 JSONB를 쓰는 게 낫다고 생각함
답변달기