Penjelasan singkat tentang kerentanan MongoBleed

 (bigdata.2minutestreaming.com)
2 poin oleh GN⁺ 2025-12-30 | 1 komentar | Bagikan ke WhatsApp
  • MongoBleed(CVE-2025-14847) adalah kerentanan kebocoran memori serius yang ada di semua versi MongoDB sejak 2017, dan memungkinkan penyerang membaca data arbitrer dari heap memory database
  • Kerentanan ini terjadi akibat bug pada jalur kompresi zlib, dan dapat dieksploitasi tanpa autentikasi hanya dengan terhubung ke database
  • Penyerang dapat mengirim permintaan terkompresi yang dimanipulasi untuk mendorong server mengalokasikan buffer dengan ukuran yang salah, lalu mengekspos memori dari operasi sebelumnya (kata sandi, API key, dll.) di dalamnya
  • MongoDB merilis patch pada 19 Desember 2025, tetapi versi EOL (3.6, 4.0, 4.2) tidak diperbaiki
  • Kerentanan yang bertahan selama 8 tahun ini memengaruhi lebih dari 210 ribu instance MongoDB yang terekspos ke internet, dan membutuhkan patch segera atau penonaktifan kompresi baik di lingkungan cloud maupun on-premises

Ikhtisar MongoBleed

  • MongoBleed(CVE-2025-14847) adalah kerentanan yang ditemukan pada jalur kompresi pesan zlib 1 di MongoDB, dan memengaruhi semua versi sejak 2017
    • Penyerang dapat membaca data arbitrer dari heap memory hanya dengan terhubung ke database tanpa autentikasi
    • Versi end-of-life (EOL) yang tidak lagi didukung seperti MongoDB 3.6, 4.0, dan 4.2 tidak diperbaiki
  • Bug ini diperkenalkan melalui PR pada Mei 2017, dan secara resmi diungkap pada 19 Desember 2025
  • MongoDB menyatakan telah menerapkan patch ke semua instance, termasuk layanan cloud Atlas

Struktur komunikasi MongoDB

  • MongoDB menggunakan protokol TCP miliknya sendiri, bukan HTTP, dan pesan dikirim dalam format BSON(Binary JSON)
  • Semua permintaan disusun sebagai perintah OP_MSG, dan saat dikompresi dibungkus dalam pesan OP_COMPRESSED
    • Pesan mencakup field seperti uncompressedSize, originalOpcode, dan compressorId
    • uncompressedSize menunjukkan ukuran yang diharapkan setelah dekompresi

Tahap eksploitasi 1 — alokasi buffer yang salah

  • Penyerang menyetel nilai uncompressedSize menjadi jauh lebih besar dari ukuran sebenarnya agar server mengalokasikan buffer besar
    • Contoh: mendeklarasikan pesan 1KB sebagai 1MB
  • Server MongoDB menggunakan ukuran yang ditentukan pengguna tanpa memverifikasi ukuran sebenarnya setelah dekompresi
    • Akibatnya, memori menyisakan struktur seperti [data aktual | sampah heap yang tidak direferensikan]
  • Karena MongoDB berbasis C++ tidak melakukan inisialisasi memori, area ini dapat berisi data sensitif dari operasi sebelumnya
    • Misalnya: kata sandi, session token, API key, data pelanggan, pengaturan sistem, dll.

Tahap eksploitasi 2 — kebocoran data

  • Penyerang mengirim input BSON yang salah untuk mendorong server mem-parsing data sampah di memori sebagai string
    • Field pertama BSON adalah string, dan mengikuti aturan null-terminated string dari bahasa C
  • Jika penyerang mengirim string tanpa karakter null terminator, server akan terus membaca data lain di memori
    • Contoh: [ { "a | password: 123\0 | apiKey: jA2sa | ip: 219.117.127.202 ]
  • Server lalu mengenali ini sebagai field BSON yang tidak valid dan mengembalikan respons error yang memuat isi tersebut
    • "errmsg": "invalid BSON field name 'a | password: 123'"
  • Dengan mengulangi proses ini, penyerang dapat memindai seluruh heap memory dan mengumpulkan informasi sensitif

Dampak dan tingkat risiko

  • Karena terjadi pada tahap pre-auth, penyerang bisa mengakses data tanpa login
  • Instance MongoDB yang terekspos ke internet langsung berada dalam risiko
    • Berdasarkan pencarian Shodan, ada lebih dari 213.000 instance MongoDB yang terbuka
  • Kerentanan ini ada sekitar 8 tahun dari 2017 hingga 2025, dan karena strukturnya sederhana, kemungkinan eksploitasi nyata cukup tinggi
  • MongoDB menyatakan “hingga saat ini tidak ada bukti eksploitasi”, tetapi tidak merilis permintaan maaf resmi atau timeline rinci

Cara mitigasi

  • Perbarui ke versi patch terbaru (8.0.17 atau lebih baru)
  • Sebagai langkah jangka pendek, mitigasi juga bisa dilakukan dengan menonaktifkan kompresi jaringan zlib
  • Pengguna MongoDB Atlas telah menerima patch

Informasi tambahan dan diskusi terkait

Ringkasan

  • MongoBleed adalah kerentanan kebocoran memori yang disebabkan oleh bug pemrosesan kompresi zlib
  • Penyerang dapat memperoleh data memori sebelumnya (kata sandi, API key, dll.) melalui permintaan terkompresi yang dimanipulasi
  • Semua versi MongoDB dari 2017 hingga 2025 terdampak, dan patch atau penonaktifan kompresi wajib dilakukan
  • Lebih dari 210 ribu instance yang terekspos ke internet berpotensi menjadi korban
  • MongoDB telah merilis patch, tetapi versi EOL tidak didukung dan respons publik dinilai terlambat

Bacaan terkait

1 komentar

 
GN⁺ 2025-12-30
Komentar Hacker News
  • Beberapa tahun lalu saya memodifikasi memory allocator di runtime Cloudflare Workers agar saat memori dibebaskan, seluruhnya ditimpa dengan pola byte tetap
    Dengan begitu, memori yang belum diinisialisasi tidak lagi menyisakan data yang bermakna
    Saya sempat memperkirakan akan ada penurunan performa, tetapi ternyata tidak ada dampak yang terukur sama sekali
    Menurut saya, siapa pun yang memakai bahasa yang tidak aman terhadap memori seharusnya melakukan ini. Bug Mongo kali ini juga kemungkinan bisa dimitigasi dengan cara seperti ini
    • macOS terbaru secara otomatis melakukan zero-out saat memori dibebaskan
      Karena itu efisiensi kompresi memori meningkat, dan secara rata-rata performa justru membaik
    • Di FreeBSD, jika variabel lingkungan MALLOC_CONF=opt.junk=free disetel, malloc akan melakukan hal yang sama
      Artinya, banyak implementasi memang sudah menyediakan fitur seperti ini sebagai opsi
    • Pada 2025, saya rasa semua allocator umum seharusnya menginisialisasi memori ke 0 secara default
      Jika butuh performa lebih, cukup buat allocator kustom untuk kebutuhan tertentu
      Ini juga akan membuka kemungkinan optimasi lain yang tidak bisa dilakukan oleh allocator sistem
    • OpenBSD mengisi memori yang baru dialokasikan dengan 0xdb, dan memori yang dibebaskan dengan 0xdf
      Berkat itu, bug use-before-initialization atau use-after-free bisa cepat terdeteksi
      Ini menjadi pengaturan default
    • Saya penasaran apakah ini sama dengan menyalakan opsi kernel init_on_free=1
  • Sepertinya penulis kurang memahami proses pengembangan internal Mongo
    Mongo dikembangkan di repositori privat internal, lalu commit dipindahkan ke repositori publik melalui Copybara
    Kebingungan soal tanggal muncul dari proses ini
    • Saya juga tidak tahu. Saya sempat merasa aneh karena tidak ada review PR, tapi sekarang jadi masuk akal
      Saya akan memperbarui tulisan untuk menjelaskan fakta ini dan perbedaan tanggalnya
  • Sepertinya penulis salah memahami timeline
    Klaster Atlas kami sudah selesai di-upgrade beberapa hari sebelum CVE diumumkan
    • Terima kasih. Tulisannya sudah saya perbarui
  • Pada sistem seperti basis data, melakukan zeroing atau poisoning saat memori dibebaskan adalah pilihan yang baik
    Zaman sekarang, kebanyakan allocator seharusnya melakukan itu secara default
    Chris di Blink memperbaiki bagian ini, dan hasilnya kemudian menyebar ke seluruh Chromium
    Dokumen terkaitnya juga menarik
    Tulisan blog Chromium
    Dokumentasi PartitionAlloc
  • Saya penasaran seberapa sering instance Mongo terekspos ke internet
    Di sisi SQL memang jarang, tapi kadang tetap ada
    • Dalam pengalaman saya, alasan keberadaan MongoDB adalah "kemalasan"
      Filosofinya adalah tidak perlu memikirkan skema, durabilitas, baca/tulis, konektivitas, dan sebagainya
      Jadi tidak mengejutkan jika keamanan juga diabaikan
    • Tiga organisasi “serius” yang saya kenal semuanya memakai Mongo untuk menghindari perancangan skema
      Sikap seperti ini mendorong pola pikir “yang penting nyaman sekarang”, dan akhirnya berujung pada masalah keamanan seperti instance DB publik
    • Menurut saya pendapat-pendapat seperti ini terlalu ekstrem
      Dalam praktiknya, SQL dan NoSQL dipakai bersama adalah hal yang umum
      NoSQL unggul untuk ketersediaan tinggi pada data skala besar, sementara SQL cocok untuk penyimpanan data relasional
      Misalnya iMessage dan sistem matchmaking EA juga memakai NoSQL
      Pada akhirnya keduanya sama-sama dibutuhkan. Bukan hubungan kompetitif, melainkan saling melengkapi
    • Menurut hasil pencarian Shodan, ada 213 ribu instance Mongo yang terekspos
    • Mengekspos server SQL akan menimbulkan akibat yang lebih serius
      Misalnya PostgreSQL, hanya dengan konfigurasi default saja bisa memperoleh hak atas seluruh sistem
      Karena itu kebanyakan orang sudah sangat paham risiko server SQL publik
  • MongoDB pada 24 Desember menyatakan “tidak ada bukti eksploitasi CVE”, tetapi kita tidak boleh lupa bahwa "tidak ada bukti bukan berarti bukti bahwa itu tidak ada"
    • Kalau begitu, menurut Anda mereka seharusnya mengatakan apa?
  • Saya tidak paham kenapa orang masih memakai Mongo
    • Replikasi (replication) mudah, dan lebih cepat daripada JSONB milik Postgres
      Secara pribadi saya juga tidak ingin memakainya, tetapi ada kasus di mana DynamoDB atau MongoDB memang tepat secara teknis
    • Ada juga lelucon bahwa orang memakainya karena “web scale”
      Video terkait
    • Dulu NoSQL sempat ngetren, tetapi pada akhirnya bermuara ke DB key-value yang sederhana
    • Logika ini terlalu agresif sehingga sulit saya terima
  • Ini mengingatkan saya pada optimisme bahwa OWASP Top 10 akan menyelesaikan kerentanan utama
    Namun buffer overflow masih tetap ada sejak 2003
    • Pada akhirnya kita seperti memberikan footgun ke semua orang
      Masalah seperti ini akan terus berulang selamanya kecuali dicegah di level bahasa
      Saya ikut bersimpati pada para pengembang Mongo
  • Setiap kali ada tulisan tentang NoSQL, terlihat jelas bahwa banyak “pengembang” tidak pernah menangani trafik berskala besar
    • Kali ini sepertinya cuma kamu sendiri yang begitu
  • MongoDB memang selalu terasa kurang bagus… tapi disebut “webscale”
    Menurut saya lebih baik pakai ToroDB atau JSONB di PostgreSQL