MongoBleed भेद्यता का सरल विवरण

 (bigdata.2minutestreaming.com)
2 पॉइंट द्वारा GN⁺ 2025-12-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • MongoBleed(CVE-2025-14847) 2017 के बाद से सभी MongoDB versions में मौजूद एक गंभीर memory leak भेद्यता है, जिससे हमलावर database की heap memory के arbitrary data को पढ़ सकते हैं
  • यह भेद्यता zlib compression path के bug के कारण होती है, और बिना authentication के सिर्फ database से connect करके इसका दुरुपयोग किया जा सकता है
  • हमलावर manipulated compressed request भेजकर server को गलत आकार का buffer allocate करने के लिए मजबूर कर सकता है, और उसके भीतर की पिछले कार्यों की memory (password, API key आदि) को उजागर कर सकता है
  • MongoDB ने 19 दिसंबर 2025 को patch जारी किया, लेकिन EOL versions (3.6, 4.0, 4.2) को ठीक नहीं किया गया
  • 8 वर्षों से मौजूद यह भेद्यता इंटरनेट पर एक्सपोज़ 2.1 लाख से अधिक MongoDB instances को प्रभावित करती है, और cloud व on-premise दोनों environments में तुरंत patch या compression disable करना ज़रूरी है

MongoBleed का अवलोकन

  • MongoBleed(CVE-2025-14847) MongoDB के zlib 1 message compression path में पाई गई भेद्यता है, जो 2017 के बाद के सभी versions को प्रभावित करती है
    • हमलावर बिना authentication के केवल database से connect करके arbitrary heap memory data पढ़ सकता है
    • MongoDB 3.6, 4.0, 4.2 जैसे end-of-life (EOL) versions को ठीक नहीं किया गया
  • यह bug मई 2017 के PR में introduce किया गया था, और 19 दिसंबर 2025 को आधिकारिक रूप से सार्वजनिक किया गया
  • MongoDB ने घोषणा की कि Atlas cloud service सहित सभी instances पर patch लागू कर दिया गया है

MongoDB communication structure

  • MongoDB HTTP के बजाय अपना TCP protocol इस्तेमाल करता है, और messages BSON(Binary JSON) फ़ॉर्मेट में भेजे जाते हैं
  • सभी requests OP_MSG command से बनी होती हैं, और compression के समय उन्हें OP_COMPRESSED message में wrap किया जाता है
    • message में uncompressedSize, originalOpcode, compressorId जैसे fields शामिल होते हैं
    • uncompressedSize decompression के बाद अपेक्षित आकार को दिखाता है

Exploit चरण 1 — गलत buffer allocation

  • हमलावर uncompressedSize value को वास्तविक आकार से काफी बड़ा सेट करके server से बड़ा buffer allocate करवाता है
    • उदाहरण: वास्तविक 1KB message को 1MB घोषित करना
  • MongoDB server decompression के बाद वास्तविक आकार को verify किए बिना user द्वारा दिए गए आकार पर भरोसा करता है
    • नतीजतन memory में [वास्तविक data | unreferenced heap garbage] जैसी संरचना बची रहती है
  • C++-आधारित MongoDB memory initialization नहीं करता, इसलिए इस क्षेत्र में पिछले कार्यों का sensitive data मौजूद हो सकता है
    • उदाहरण: password, session token, API key, customer data, system settings आदि

Exploit चरण 2 — data leak

  • हमलावर गलत BSON input भेजकर server को memory के garbage data को string की तरह parse करने के लिए प्रेरित करता है
    • BSON का पहला field string होता है, और C language के null-terminated string नियम का पालन करता है
  • अगर हमलावर null terminator के बिना string भेजता है, तो server memory में मौजूद अन्य data भी पढ़ लेता है
    • उदाहरण: [ { "a | password: 123\0 | apiKey: jA2sa | ip: 219.117.127.202 ]
  • server इसे गलत BSON field मानकर error message में वही सामग्री शामिल करके response देता है
    • "errmsg": "invalid BSON field name 'a | password: 123'"
  • इस प्रक्रिया को दोहराकर हमलावर पूरी heap memory को scan करते हुए sensitive information इकट्ठा कर सकता है

प्रभाव और जोखिम

  • यह pre-auth चरण में होता है, इसलिए हमलावर बिना login के data तक पहुँच सकता है
  • इंटरनेट पर एक्सपोज़ MongoDB instances तुरंत जोखिम में हैं
    • Shodan search के अनुसार 213,000 से अधिक MongoDB instances सार्वजनिक रूप से उपलब्ध हैं
  • 2017 से 2025 तक लगभग 8 साल तक मौजूद इस भेद्यता के वास्तविक exploit होने की संभावना इसकी सरल संरचना के कारण अधिक है
  • MongoDB ने कहा कि “अब तक exploit का कोई प्रमाण नहीं है”, लेकिन औपचारिक माफ़ी या विस्तृत timeline सार्वजनिक नहीं की गई

Mitigation तरीके

  • नवीनतम patched version (8.0.17 या उससे ऊपर) में update करें
  • अल्पकालिक उपाय के रूप में zlib network compression disable करके भी जोखिम कम किया जा सकता है
  • MongoDB Atlas users पर patch पहले ही लागू किया जा चुका है

अतिरिक्त जानकारी और संबंधित चर्चा

  • Elastic security team lead ने इसका नाम ‘MongoBleed’ रखा और PoC(Python script) प्रकाशित किया
    • MongoDB और Elastic search और analytics functionality के क्षेत्र में प्रतिस्पर्धी हैं
  • संबंधित resources:

सारांश

  • MongoBleed, zlib compression handling bug के कारण पैदा हुई एक memory leak भेद्यता है
  • हमलावर manipulated compressed request के जरिए पिछली memory का data (password, API key आदि) हासिल कर सकता है
  • 2017~2025 के सभी MongoDB versions प्रभावित हैं, और patch या compression disable करना अनिवार्य है
  • इंटरनेट पर एक्सपोज़ 2.1 लाख से अधिक instances संभावित प्रभावित लक्ष्य हैं
  • MongoDB ने patch जारी किया है, लेकिन EOL versions के लिए support न होना और सार्वजनिक प्रतिक्रिया में देरी पर सवाल उठे हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-12-30
Hacker News की राय
  • कुछ साल पहले मैंने Cloudflare Workers runtime के memory allocator में बदलाव किया था, ताकि free करते समय सारी memory को एक fixed byte pattern से overwrite किया जाए
    इसकी वजह से uninitialized memory में कोई अर्थपूर्ण data नहीं बचता था
    performance hit की उम्मीद थी, लेकिन वास्तव में कोई measurable impact नहीं था
    मेरा मानना है कि memory-safe नहीं होने वाली language इस्तेमाल करने वाले सभी लोगों को ऐसा करना चाहिए। Mongo का यह bug भी शायद इस तरीके से mitigate किया जा सकता था
    • आधुनिक macOS memory free करते समय अपने-आप zero-out करता है
      इससे memory compression efficiency बढ़ती है, और औसतन performance भी बेहतर हो जाती है
    • FreeBSD में MALLOC_CONF=opt.junk=free environment variable सेट करने पर malloc यही behavior करता है
      यानी कई implementations पहले से यह feature option के रूप में देती हैं
    • मेरा मानना है कि 2025 में सभी general-purpose allocators को default रूप से memory को 0 से initialize करना चाहिए
      अगर ज्यादा performance चाहिए, तो specific use case के लिए custom allocator लिखा जा सकता है
      इससे ऐसे दूसरे optimizations भी संभव होंगे जो system allocator में नहीं किए जा सकते
    • OpenBSD newly allocated memory को 0xdb और freed memory को 0xdf से भरता है
      इससे use-before-initialization और use-after-free bugs जल्दी पकड़ में आते हैं
      यह default setting है
    • क्या यह kernel के init_on_free=1 option को on करने जैसा ही behavior है?
  • लगता है कि लेखक Mongo की internal development process को ठीक से नहीं समझ पाया
    Mongo पहले internal private repository में develop करता है, फिर Copybara के जरिए commits को public repository में ले जाता है
    तारीखों को लेकर जो confusion है, वह इसी process से आया है
    • मुझे भी यह पता नहीं था। PR reviews न होना अजीब लगा था, लेकिन अब समझ में आया
      मैं post update करके इस बात और तारीखों के अंतर को explain करूँगा
  • लगता है लेखक ने timeline गलत समझी
    हमारे Atlas clusters CVE घोषित होने से कुछ दिन पहले ही upgrade हो चुके थे
    • धन्यवाद। मैंने post update कर दी है
  • database जैसे systems में memory free करते समय zeroing या poisoning करना एक अच्छा विकल्प है
    आजकल तो ज़्यादातर allocators को default रूप से ऐसा करना चाहिए
    Blink में Chris ने इस हिस्से को improve किया था, और उसका असर पूरे Chromium में फैल गया
    इससे जुड़ी documentation भी दिलचस्प है
    Chromium blog post
    PartitionAlloc documentation
  • यह जानने की जिज्ञासा है कि Mongo instances कितनी बार internet पर exposed मिलते हैं
    SQL की दुनिया में यह दुर्लभ है, लेकिन कभी-कभी होता है
    • मेरे अनुभव में MongoDB के अस्तित्व की वजह "आलस्य" है
      इसकी philosophy है कि schema, durability, reads/writes, connectivity वगैरह किसी चीज़ की चिंता न करनी पड़े
      इसलिए security की भी चिंता न की जाए, यह चौंकाने वाली बात नहीं है
    • जिन 3 “serious” organizations को मैं जानता हूँ, वे सभी Mongo सिर्फ schema design से बचने के लिए इस्तेमाल कर रहे थे
      ऐसा रवैया “अभी के लिए आसानी” वाली सोच पैदा करता है, और आखिरकार public DB instances जैसी security समस्याओं तक ले जाता है
    • ये राय कुछ ज़्यादा ही चरम लगती हैं
      व्यवहार में SQL और NoSQL को साथ में इस्तेमाल करना आम है
      NoSQL बड़े पैमाने के data में high availability के लिए अच्छा है, और SQL relational data storage के लिए उपयुक्त है
      उदाहरण के लिए iMessage और EA की matchmaking systems भी NoSQL इस्तेमाल करती हैं
      आखिरकार दोनों की ज़रूरत होती है। ये प्रतिद्वंद्वी नहीं, बल्कि पूरक हैं
    • Shodan search results के मुताबिक 2 लाख 13 हज़ार Mongo instances exposed हैं
    • अगर SQL server expose हो जाए तो नतीजे और गंभीर हो सकते हैं
      उदाहरण के लिए PostgreSQL default settings के साथ ही पूरे system पर अधिकार पा सकता है
      इसलिए ज़्यादातर लोग public SQL servers के जोखिम को अच्छी तरह जानते हैं
  • MongoDB ने 24 दिसंबर को कहा था कि “CVE exploitation का कोई सबूत नहीं है”, लेकिन यह नहीं भूलना चाहिए कि “सबूत न होना, अस्तित्व न होने का सबूत नहीं है”
    • तो फिर आपको क्या लगता है, उन्हें क्या कहना चाहिए था?
  • समझ नहीं आता कि लोग अब भी Mongo क्यों इस्तेमाल करते हैं
    • replication आसान है, और यह Postgres के JSONB से तेज़ है
      मैं खुद इसे पसंद नहीं करता, लेकिन कुछ मामलों में DynamoDB या MongoDB तकनीकी रूप से सही विकल्प हो सकते हैं
    • यह मज़ाक भी है कि लोग इसे “web scale” की वजह से इस्तेमाल करते हैं
      संबंधित वीडियो
    • पहले NoSQL का बहुत hype था, लेकिन आखिरकार बात एक साधारण key-value DB तक आ गई
    • यह तर्क इतना आक्रामक है कि इसे स्वीकार करना मुश्किल है
  • इससे OWASP Top 10 के मुख्य vulnerabilities को हल कर देने वाले आशावाद की याद आती है
    लेकिन buffer overflow 2003 से अब तक मौजूद है
    • आखिर में हमने बस सबके हाथ में एक footgun दे दिया
      जब तक ऐसी चीज़ों को language level पर नहीं रोका जाएगा, ये समस्याएँ हमेशा दोहराई जाएँगी
      Mongo developers के लिए संवेदना है
  • हर बार जब NoSQL पर कोई post आती है, तब साफ दिखता है कि बहुत से “developers” ने कभी large-scale traffic handle नहीं किया
    • इस बार तो लगता है कि यह सिर्फ तुम ही हो
  • MongoDB हमेशा से खास अच्छा नहीं रहा… फिर भी इसे “webscale” कहा जाता है
    मुझे लगता है ToroDB या PostgreSQL का JSONB इस्तेमाल करना बेहतर होगा