MongoBleed açığına kısa bir açıklama

 (bigdata.2minutestreaming.com)
2 puan yazan GN⁺ 2025-12-30 | 1 yorum | WhatsApp'ta paylaş
  • MongoBleed(CVE-2025-14847), 2017’den bu yana tüm MongoDB sürümlerinde bulunan ciddi bir bellek sızıntısı açığıdır; saldırganlar veritabanının heap belleğindeki rastgele verileri okuyabilir
  • Açık, zlib sıkıştırma yolundaki bir hatadan kaynaklanır ve kimlik doğrulama olmadan, yalnızca veritabanına bağlanarak istismar edilebilir
  • Saldırganlar manipüle edilmiş sıkıştırılmış istekler göndererek sunucunun yanlış boyutta bir arabellek ayırmasını sağlayabilir ve bunun içindeki önceki işlemlere ait bellek verilerini (parolalar, API anahtarları vb.) ortaya çıkarabilir
  • MongoDB, 19 Aralık 2025’te bir yama yayımladı, ancak EOL sürümleri (3.6, 4.0, 4.2) düzeltilmedi
  • 8 yıldır var olan bu açık, internete açık 210 binden fazla MongoDB örneğini etkiliyor; hem bulut hem de şirket içi ortamlarda derhal yama uygulanması veya sıkıştırmanın devre dışı bırakılması gerekiyor

MongoBleed genel bakış

  • MongoBleed(CVE-2025-14847), MongoDB’nin zlib 1 mesaj sıkıştırma yolunda keşfedilen bir açıktır ve 2017’den bu yana tüm sürümleri etkiler
    • Saldırganlar kimlik doğrulama olmadan yalnızca veritabanına bağlanarak rastgele heap bellek verilerini okuyabilir
    • MongoDB 3.6, 4.0, 4.2 gibi destek sonu (EOL) sürümleri düzeltilmedi
  • Bu hata, Mayıs 2017’deki bir PR ile sisteme girdi ve 19 Aralık 2025’te resmen açıklandı
  • MongoDB, Atlas bulut hizmeti dahil tüm örneklere yamaların uygulandığını duyurdu

MongoDB iletişim yapısı

  • MongoDB, HTTP yerine kendi TCP protokolünü kullanır ve mesajlar BSON (Binary JSON) biçiminde iletilir
  • Tüm istekler OP_MSG komutundan oluşur; sıkıştırıldığında OP_COMPRESSED mesajıyla sarılır
    • Mesajda uncompressedSize, originalOpcode, compressorId gibi alanlar bulunur
    • uncompressedSize, sıkıştırma açıldıktan sonraki beklenen boyutu gösterir

İstismar aşaması 1 — hatalı arabellek ayırma

  • Saldırgan, uncompressedSize değerini gerçekte olduğundan aşırı büyük ayarlayarak sunucunun büyük bir arabellek ayırmasını sağlar
    • Örnek: Gerçekte 1KB olan bir mesajı 1MB olarak bildirmek
  • MongoDB sunucusu, sıkıştırma açıldıktan sonra gerçek boyutu doğrulamadan kullanıcının belirttiği boyuta güvenir
    • Sonuç olarak bellekte [gerçek veri | başvurulmayan heap çöp verisi] biçiminde bir yapı kalır
  • C++ tabanlı MongoDB bellek başlatma yapmadığı için bu alanda önceki işlemlerden kalma hassas veriler bulunabilir
    • Örnek: parolalar, oturum token’ları, API anahtarları, müşteri verileri, sistem ayarları vb.

İstismar aşaması 2 — veri sızdırma

  • Saldırgan, hatalı BSON girdisi göndererek sunucunun bellekteki çöp verileri bir dize olarak ayrıştırmasını tetikler
    • BSON’un ilk alanı bir dizedir ve C dilindeki null sonlandırmalı dize (null-terminated string) kuralını izler
  • Saldırgan null sonlandırma karakteri olmayan bir dize gönderirse, sunucu bellekteki diğer verileri de okumaya devam eder
    • Örnek: [ { "a | password: 123\0 | apiKey: jA2sa | ip: 219.117.127.202 ]
  • Sunucu bunu hatalı bir BSON alanı olarak algılar ve yanıtındaki hata mesajına ilgili içeriği ekler
    • "errmsg": "invalid BSON field name 'a | password: 123'"
  • Bu süreç tekrarlandığında saldırgan tüm heap belleği tarayarak hassas bilgileri toplayabilir

Etki ve risk düzeyi

  • Açık kimlik doğrulama öncesi (pre-auth) aşamada ortaya çıktığı için saldırganlar giriş yapmadan verilere erişebilir
  • İnternete açık MongoDB örnekleri anında risk altındadır
    • Shodan aramasına göre 213.000’den fazla MongoDB örneği herkese açıktır
  • 2017’den 2025’e kadar yaklaşık 8 yıl boyunca varlığını sürdüren bu açık, yapısının basitliği nedeniyle fiilen istismar edilme olasılığı yüksektir
  • MongoDB, “şu ana kadar istismar edildiğine dair bir kanıt yok” dedi, ancak resmî bir özür veya ayrıntılı bir zaman çizelgesi yayımlamadı

Azaltma yöntemleri

  • Güncel yamalı sürüme (8.0.17 ve üzeri) güncelleyin
  • Kısa vadede zlib ağ sıkıştırmasını devre dışı bırakmak da bir azaltma yöntemi olabilir
  • MongoDB Atlas kullanıcılarında yama zaten uygulanmış durumda

Ek bilgiler ve ilgili tartışmalar

Özet

  • MongoBleed, zlib sıkıştırma işleme hatası nedeniyle ortaya çıkan bir bellek sızıntısı açığıdır
  • Saldırganlar manipüle edilmiş sıkıştırılmış istekler yoluyla önceki bellek verilerini (parolalar, API anahtarları vb.) elde edebilir
  • 2017–2025 arasındaki tüm MongoDB sürümleri etkilenir; yama veya sıkıştırmayı devre dışı bırakma zorunludur
  • İnternete açık 210 binden fazla örnek potansiyel risk altındadır
  • MongoDB yama yayımladı, ancak EOL sürümlerine destek verilmemesi ve kamuya açık yanıtın gecikmesi eleştiriliyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-12-30
Hacker News görüşleri
  • Birkaç yıl önce Cloudflare Workers runtime’ındaki memory allocator’ı değiştirip, serbest bırakma sırasında tüm belleğin sabit bir bayt deseniyle üzerine yazılmasını sağlamıştım
    Bu sayede başlatılmamış bellekte anlamlı veri kalmıyordu
    Performans düşüşü bekliyordum ama gerçekte ölçülebilir hiçbir etkisi olmadı
    Bellek açısından güvenli olmayan diller kullanan herkesin bunu yapması gerektiğini düşünüyorum. Bu Mongo hatası da muhtemelen bu şekilde hafifletilebilirdi
    • Güncel macOS sürümleri, bellek serbest bırakılırken otomatik olarak zero-out yapıyor
      Bu sayede bellek sıkıştırma verimliliği artıyor ve ortalamada performansın hatta iyileştiği söyleniyor
    • FreeBSD’de MALLOC_CONF=opt.junk=free ortam değişkeni ayarlanırsa malloc aynı davranışı sergiliyor
      Yani pek çok implementasyon bu özelliği zaten opsiyon olarak sunuyor
    • 2025 yılında tüm genel amaçlı allocator’ların varsayılan olarak belleği sıfırlaması gerektiğini düşünüyorum
      Daha fazla performans gerekirse belirli kullanım senaryolarına uygun özel allocator yazılabilir
      Böylece sistem allocator’ında mümkün olmayan başka optimizasyonlar da yapılabilir
    • OpenBSD, yeni ayrılan belleği 0xdb, serbest bırakılan belleği ise 0xdf ile dolduruyor
      Bu sayede use-before-initialization ve use-after-free hataları hızlıca yakalanabiliyor
      Bu da varsayılan ayar olarak geliyor
    • Acaba bu, çekirdekte init_on_free=1 seçeneğini açmakla aynı şey mi diye merak ediyorum
  • Yazının yazarı Mongo’nun dahili geliştirme sürecini çok iyi bilmiyor gibi görünüyor
    Mongo, geliştirmeyi dahili özel repository üzerinde yapıp sonra commit’leri Copybara ile açık repository’ye taşıyor
    Tarih karmaşası da bu süreçten kaynaklanıyor
    • Bunu ben de bilmiyordum. PR incelemesi olmaması bana tuhaf gelmişti ama şimdi anlaşılıyor
      Yazıyı güncelleyip bu durumu ve tarih farkını açıklayacağım
  • Yazının yazarı zaman çizelgesini yanlış anlamış gibi görünüyor
    Bizim Atlas cluster’larımız CVE yayımlanmadan birkaç gün önce zaten yükseltilmişti
    • Teşekkürler. Yazıyı güncelledim
  • Veritabanı gibi sistemlerde, bellek serbest bırakılırken zeroing veya poisoning yapmak iyi bir tercih
    Günümüzde çoğu allocator’un bunu varsayılan olarak yapması gerekir
    Blink tarafında Chris bu alanı iyileştirdi ve sonuçları tüm Chromium’a yayıldı
    İlgili dokümanlar da ilginç
    Chromium blog yazısı
    PartitionAlloc dokümanı
  • Mongo instance’larının internete ne kadar sık açık olduğunu merak ediyorum
    SQL tarafında nadir ama zaman zaman görülüyor
    • Benim deneyimime göre MongoDB’nin varlık nedeni “tembellik”
      Şema, dayanıklılık, okuma/yazma, bağlantı gibi hiçbir şeyi dert etmemek üzerine kurulu bir anlayış var
      Bu yüzden güvenliğin de önemsenmemesi şaşırtıcı değil
    • Bildiğim üç “ciddi” kurumun da Mongo kullanma nedeni şema tasarımından kaçınmaktı
      Bu yaklaşım “şimdilik rahat edelim” düşüncesine dönüşüyor ve sonunda halka açık DB instance’ı gibi güvenlik sorunlarına yol açıyor
    • Bu yorumlar bana fazla uç geliyor
      Gerçekte SQL ve NoSQL’i birlikte kullanmak yaygın bir durum
      NoSQL, büyük ölçekli veride yüksek erişilebilirlik açısından güçlü; SQL ise ilişkisel veri saklama için uygun
      Örneğin iMessage ya da EA’in matchmaking sistemi de NoSQL kullanıyor
      Sonuçta ikisine de ihtiyaç var. Rakip değil, birbirini tamamlayan teknolojiler
    • Shodan arama sonucuna göre internete açık 213 bin Mongo instance’ı var
    • SQL sunucusunu açığa çıkarmak daha da ciddi sonuçlar doğurur
      Örneğin PostgreSQL yalnızca varsayılan ayarlarla bile tüm sistem yetkisine sahip olabilir
      Bu yüzden çoğu insan internete açık SQL sunucularının riskini iyi bilir
  • MongoDB, 24 Aralık’ta “CVE’nin istismar edildiğine dair kanıt yok” dedi ama “kanıtın olmaması, yokluğun kanıtı değildir” sözünü unutmamak gerekir
    • O halde sizce ne söylemeleri gerekiyordu?
  • İnsanların neden hâlâ Mongo kullandığını anlamıyorum
    • Replication kolay ve Postgres’in JSONB’sinden daha hızlı
      Ben de şahsen kullanmak istemem ama DynamoDB ya da MongoDB’nin teknik olarak uygun olduğu durumlar var
    • “web scale” olduğu için kullanıldığına dair bir şaka da var
      ilgili video
    • Eskiden NoSQL modaydı ama sonunda iş basit bir key-value DB’ye dönüştü
    • Bu mantık bana fazla saldırgan geliyor, kabul etmesi zor
  • Bu bana OWASP Top 10’un temel zafiyetleri çözeceğine dair iyimserliği hatırlatıyor
    Ama buffer overflow 2003’ten beri hâlâ var
    • Sonuçta herkesin eline bir footgun verilmiş oldu
      Bu tür sorunlar dil seviyesinde engellenmedikçe sonsuza kadar tekrar edecektir
      Mongo geliştiricilerine geçmiş olsun
  • NoSQL ile ilgili her yazı çıktığında, birçok “geliştirici”nin büyük ölçekli trafiği hiç yönetmemiş olduğu ortaya çıkıyor
    • Bu sefer öyle görünen tek kişi sensin
  • MongoDB her zaman pek iyi değildi… ama adına “webscale” dendi
    Bence ToroDB ya da PostgreSQL’in JSONB’si kullanmak daha iyi