몇 년 전 나는 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을 사용함
결국 둘 다 필요함. 경쟁 관계가 아니라 보완 관계임
Hacker News 의견들
덕분에 초기화되지 않은 메모리에는 의미 있는 데이터가 남지 않게 되었음
성능 저하를 예상했지만 실제로는 측정 가능한 영향이 전혀 없었음
메모리 안전하지 않은 언어를 쓰는 사람이라면 모두 이렇게 해야 한다고 생각함. 이번 Mongo 버그도 이런 방식으로 완화할 수 있었을 것임
이 덕분에 메모리 압축 효율이 높아지고, 평균적으로는 오히려 성능이 향상된다고 함
MALLOC_CONF=opt.junk=free환경 변수를 설정하면 malloc이 같은 동작을 수행함즉, 이미 많은 구현체가 이런 기능을 옵션으로 제공하고 있음
성능이 더 필요하면 특정 용도에 맞게 커스텀 할당기를 작성하면 됨
시스템 할당기에서는 불가능한 다른 최적화도 가능해질 것임
0xdb, 해제된 메모리를0xdf로 채움덕분에 use-before-initialization이나 use-after-free 버그를 빠르게 잡을 수 있음
이게 기본 설정으로 되어 있음
init_on_free=1옵션을 켜는 것과 같은 동작인지 궁금함Mongo는 내부 비공개 저장소에서 개발 후, Copybara를 통해 공개 저장소로 커밋을 옮김
날짜 혼란은 이 과정에서 생긴 것임
글을 업데이트해서 이 사실과 날짜 차이를 설명할 예정임
우리 Atlas 클러스터는 CVE가 발표되기 며칠 전에 이미 업그레이드가 완료되었음
요즘은 대부분의 할당기가 기본적으로 그렇게 해야 함
Blink에서 Chris가 이 부분을 개선했고, 그 결과가 Chromium 전체로 확산되었음
관련 문서도 흥미로움
Chromium 블로그 글
PartitionAlloc 문서
SQL 쪽에서는 드물지만 가끔 있긴 함
스키마, 내구성, 읽기/쓰기, 연결성 등 아무것도 신경 쓰지 않아도 된다는 철학임
그래서 보안도 신경 쓰지 않는 게 놀랍지 않음
이런 태도는 “지금 당장 편하자”는 생각으로 이어지고, 결국 공개 DB 인스턴스 같은 보안 문제로 연결됨
실제로는 SQL과 NoSQL을 함께 사용하는 게 일반적임
NoSQL은 대규모 데이터의 고가용성에 강점이 있고, SQL은 관계형 데이터 저장에 적합함
예를 들어 iMessage나 EA의 매치메이킹 시스템도 NoSQL을 사용함
결국 둘 다 필요함. 경쟁 관계가 아니라 보완 관계임
예를 들어 PostgreSQL은 기본 설정만으로도 시스템 전체 권한을 가질 수 있음
그래서 대부분의 사람들은 공개 SQL 서버의 위험성을 잘 알고 있음
개인적으로는 쓰고 싶지 않지만, DynamoDB나 MongoDB가 기술적으로 적합한 경우도 있음
관련 영상
하지만 버퍼 오버플로우는 2003년부터 여전히 존재함
이런 문제는 언어 차원에서 막지 않는 한 영원히 반복될 것임
Mongo 개발자들에게 위로를 보냄
차라리 ToroDB나 PostgreSQL의 JSONB를 쓰는 게 낫다고 생각함