CERT ने dnsmasq की 6 गंभीर सुरक्षा कमजोरियों के लिए CVE सार्वजनिक किए

• CERT ने 11 मई 2026 को dnsmasq की 6 गंभीर सुरक्षा कमजोरियों के लिए CVE सेट सार्वजनिक किया
• ये सभी कमजोरियां पुराने बग हैं, और बहुत पुराने वर्ज़न को छोड़कर लगभग सभी dnsmasq वर्ज़न प्रभावित हैं
• CVE की जानकारी पहले से vendors के साथ साझा की गई थी, और हर vendor को dnsmasq पैकेज का patched version समय पर वितरित करना चाहिए
• stable release dnsmasq 2.92 पर patch लागू करके 2.92rel2 बनाया गया है, और इसे मौजूदा डाउनलोड स्थान से प्राप्त किया जा सकता है
• जल्द ही dnsmasq-2.93rc1 टैग बनाया जाएगा, और testing के बाद लगभग एक हफ्ते के भीतर 2.93 release का लक्ष्य है

---

dnsmasq कमजोरियों का खुलासा और patch

• CERT ने 11 मई 2026 को dnsmasq की 6 गंभीर सुरक्षा कमजोरियों के लिए CVE सेट सार्वजनिक किया
• ये कमजोरियां सभी पुराने बग हैं, और बहुत पुराने वर्ज़न को छोड़कर लगभग सभी dnsmasq वर्ज़न पर लागू होती हैं
• CVE की जानकारी vendors को पहले से दी गई थी, और हर vendor को dnsmasq पैकेज का patched version समय पर वितरित करना चाहिए
• विवरण और patch https://thekelleys.org.uk/dnsmasq/CVE/ पर देखे जा सकते हैं
• stable release dnsmasq 2.92 पर patch लागू करके 2.92rel2 बनाया गया है, और इसे मौजूदा डाउनलोड स्थान से प्राप्त किया जा सकता है
• development tree में भी उसी समय fix commits जोड़े जाने वाले हैं; इनमें कुछ backport जैसे patch का उपयोग करते हैं, जबकि कुछ root cause को संबोधित करने वाले अधिक व्यापक rewrite हैं

AI-आधारित रिपोर्ट में वृद्धि और 2.93 की योजना

• पिछले कुछ महीनों में AI-आधारित security research के कारण bug reports में काफी वृद्धि हुई है, और deduplication व bug classification में बहुत समय लग रहा है
• बग्स को उन मामलों में बांटा गया जिनमें vendor pre-disclosure ज़रूरी है, और उन मामलों में जिन्हें सार्वजनिक होने के तुरंत बाद ठीक करना बेहतर है; यह विभाजन अनिवार्य रूप से कुछ हद तक व्यक्तिपरक है
• चूंकि एक ही बग को कई “good guys” बार-बार खोज रहे थे, इसलिए यह भी संभव है कि “bad guys” ने भी उन्हें ढूंढ लिया हो, इसलिए लंबे embargo की प्रभावशीलता बहुत अधिक नहीं मानी गई
• embargo coordination और backport उपलब्ध कराने में सभी प्रतिभागियों के लिए काफी समय और मेहनत लगती है
• ज़्यादातर बग्स को आने वाली releases में ठीक करना, ताकि नई dnsmasq release को यथासंभव bug-free बनाया जा सके, प्राथमिकता है
• घोषणा से पहले के कुछ हफ्तों में git repository में कई security fix commits जोड़े गए, जो इसी दिशा को दर्शाते हैं
• जल्द ही dnsmasq-2.93rc1 टैग बनाने की योजना है, और stable version 2.93 को यथासंभव जल्दी जारी करना लक्ष्य है
• release candidate की testing महत्वपूर्ण है, इसलिए जो उपयोगकर्ता कर सकते हैं उन्हें जल्दी test करना चाहिए
• अगर सब कुछ सुचारु रहा, तो 2.93 लगभग एक हफ्ते के भीतर आ सकता है
• AI-जनित bug reports की “tsunami” थमने के कोई संकेत नहीं दिख रहे, इसलिए यही प्रक्रिया जल्द फिर दोहराई जा सकती है
• 2.93 में चल रहे bug flow को यथासंभव अधिक शामिल करने और समय पर release देने के बीच तनाव है, और प्राथमिकता समय पर release को दी गई है

[GN⁺]

Hacker News की टिप्पणियाँ

• ऐसा लग रहा है कि C में लिखे गए कोड को memory-safe language में बदलना अब सचमुच एक जरूरी मोड़ पर पहुंच गया है
  हाल में मिलने वाली ज़्यादातर vulnerabilities सीधे memory-unsafe languages से जुड़ी हैं, और DNS/DHCP server को Rust या Go में, अगर संभव हो तो unsafe के बिना, नहीं लिखा जा सकता—यह तर्क देना अब बहुत मुश्किल लगता है

  • https://news.ycombinator.com/item?id=47943499 — coreutils को नई Rust implementation से बदलने की कोशिश में 44 CVE निकले थे। मुफ्त का खाना कहीं नहीं मिलता
  • समस्या भाषा नहीं, बल्कि यह काम करने वाले talent की कमी है
    AI security researchers कम से कम कुछ तो कर रहे हैं। अगर सब कुछ Rust में फिर से लिखना इतना आसान होता, तो ऐसे incident के अगले ही दिन उसका मजबूत Rust replacement आ जाना चाहिए था
    ऐसा नहीं होता, क्योंकि इस तरह के काम से GitHub stars मिलना आसान नहीं है
  • शायद समस्या dynamic memory को देखने के तरीके में हो सकती है
    “अधिकतम आकार नहीं पता, इसलिए सब कुछ dynamic होना चाहिए” — क्या यह सच में सही है? अगर कोई program input के स्वीकार्य अधिकतम आकार की घोषणा करे, और उससे आगे error दे या ring buffer इस्तेमाल करे, तो यह दुनिया का अंत नहीं है
    अगर आकार पता हो, तो उसी हिसाब से design किया जा सकता है। RAM सीमित है, फिर भी उसके भीतर हर layer को ऐसे design करना कि मानो सब कुछ असीमित हो, अजीब लगता है
    Rust में बदलना बहुत बड़ा समय-नाश लगता है, और यह उस मूल समस्या को हल नहीं करता कि program को system resources की सीमित वास्तविकता के हिसाब से model नहीं किया जा रहा। यह सिर्फ memory की बात नहीं है। Chrome का user devices पर 4GB model चढ़ाना भी कुछ वैसा ही है
  • सहमत नहीं। संभावित vulnerabilities खोजने वाले AI agents की वजह से सुरक्षा उपाय साफ़ तौर पर बेहतर हो रहे हैं

• https://xchglabs.com/blog/dnsmasq-five-cves.html

• मैं सोच रहा था कि क्या OpenWRT ने नया build जारी किया है, लेकिन जवाब है अभी नहीं, काम चल रहा है
  https://forum.openwrt.org/t/dnsmasq-set-of-serious-cves/2500...

  • DD-WRT भी इस पर काम कर रहा है
    https://github.com/mirror/dd-wrt/issues/465
    https://svn.dd-wrt.com/changeset/64944
    https://svn.dd-wrt.com/changeset/64905
    release को “coming soon” कहा गया है

• मेरा MaraDNS AI-सहायित security audit के दौर में काफी व्यापक रूप से audit किया गया है
  2023 के बाद से एक भी गंभीर security bug नहीं मिला [1]
  auditors ने जो पाया, वह बस इतना था कि “Deadwood को fully recursive mode में कोई अजीब packet मिले तो resources रिलीज़ होने में सामान्य से ज़्यादा समय लगता है” [2], या “MaraDNS में शामिल एक helper utility 2022 से compile भी नहीं हो रही थी, लेकिन उसमें buffer overflow केवल तब है जब $HOME 50 characters से लंबा हो” [3]
  अब जब MaraDNS को गहराई वाले वास्तविक security audits मिल रहे हैं, यह मेरे लिए बहुत संतोषजनक है कि यह काफ़ी सुरक्षित है
  [1] https://samboy.github.io/MaraDNS/webpage/security.html
  [2] https://github.com/samboy/MaraDNS/discussions/136
  [3] https://github.com/samboy/MaraDNS/pull/137

  • अगर Lua 5.1 को library की तरह बनाकर load नहीं किया गया, बल्कि Lunacy के साथ bundle किया गया है, और वह भी 2012 version है, तो शायद यह CVE-2014-5461 जैसी समस्याओं से भी प्रभावित हो सकता है
    Lua में भी security fixes की कमी नहीं रही है
  • फिर भी MaraDNS, dnsmasq जितना लोकप्रिय नहीं है
    मेरे भी कुछ अपने लिखे हुए libraries हैं, और 1991 के बाद से उनमें एक भी गंभीर security bug नहीं मिला। बेशक, कोई उनका उपयोग नहीं करता
    मैं उपलब्धि को कम नहीं आंक रहा, लेकिन ऐसे दावों को user base के संदर्भ में देखना ज़रूरी है
  • पहले जब DNS server सेट कर रहा था, तब dnsmasq के “सब कुछ कर देने वाले” तरीके की जगह MaraDNS मिलना अच्छा लगा, और इससे भी ज़्यादा अहम यह कि उसके बाद मुझे उसकी चिंता ही नहीं करनी पड़ी
  • जिज्ञासा है, लेकिन यहां कहना क्या चाहा जा रहा है, समझ नहीं आता। क्या मतलब यह है कि dnsmasq का एक alternative है, या यह कि आपका software somehow “बेहतर” है?
    यह self-promotion dnsmasq की चर्चा में लगभग कोई मूल्य नहीं जोड़ता
    ज़्यादा इस्तेमाल होने वाले software की ज़्यादा जांच होती है, और उनमें ज़्यादा bugs व edge cases सामने आते हैं
  • अच्छा काम। लेकिन 2026 में भी core networking tools को C जैसी कमजोर भाषा में लिखते रहना हैरानी की बात है

• शुक्र है कि यह software उन लाखों devices में तो इस्तेमाल नहीं हो रहा होगा जिन्हें शायद ही कभी updates मिलते हों

  • जब vendor कहता है कि “हम तुम्हें अपनी मर्ज़ी से इस्तेमाल नहीं करने देंगे”, तब अपने hardware पर सीधा control होना अच्छी बात है
  • कम से कम ज्यादातर मामलों में यह उन devices पर चलता है जहां client पहले Wi-Fi पर authenticate किए बिना या Ethernet port में physically plug किए बिना packet भेज ही नहीं सकता
  • Y2K26?

• यह काफ़ी गंभीर है
  “ऐसा remote attacker जो DNS query कर सकता हो या DNS response दे सकता हो, heap पर बड़ा out-of-bounds write कर सकता है”
  गलत DNS response “infinite loop trigger कर सकता है, जिससे dnsmasq किसी भी query का जवाब देना बंद कर दे”
  malicious DHCP requests buffer overflow करा सकते हैं

• AI bug report tsunami हर project में नहीं है। ऊपर बताया गया, MaraDNS में तो नहीं था
  मेरा मानना है कि djbdns और tinydns में भी नहीं रहा होगा। अगर होता, तो ज़ोर-शोर से बताया गया होता
  मैं कभी समझ नहीं पाया कि कुछ projects बेहद लोकप्रिय क्यों हो जाते हैं और कुछ नहीं
  ऐसा भी लगता है कि “publicly disclose करने के लिए बहुत खतरनाक” कहे जाने वाले tools सब projects को scan करते हैं, लेकिन संपर्क सिर्फ उन्हीं से करते हैं जहां issue मिलता है। ऐसा करने से उन्हें यह स्वीकार नहीं करना पड़ता कि उनके tools को कुछ मिला ही नहीं

  • ऐसी चीज़ें popular projects में होती हैं

• मुझे dnsmasq इस्तेमाल करना कभी पसंद नहीं आया। ऐसा लगता था जैसे एक ही tool में बहुत कुछ ठूंस दिया गया हो
  local caching resolver, DHCP server, और TFTP/PXE boot setup को मैं हमेशा अलग-अलग configure करना पसंद करता था

  • कुछ लोगों के लिए dnsmasq features में ऐसी चीज़ें हैं जिनका replacement आसान नहीं है
    उदाहरण के लिए *.example.com queries को किसी खास upstream server पर भेजना, phishing sites के लिए NXDOMAIN लौटाना, या *.example.org पर resolve हुए सभी IPs को policy routing के लिए ipset में जोड़ना
    आख़िरी feature FreeBSD पर भी काम करता है, जबकि BSD में ipset नहीं है। *.example_xyz.com lists बहुत बड़ी हो सकती हैं, और हाल के dnsmasq versions इसे efficiently handle करने के लिए जाने जाते हैं
  • इसी सोच की वजह से मैंने बहुत पहले DNS hosting के लिए MaraDNS इस्तेमाल करना शुरू किया
    10 में 10, कोई पछतावा नहीं, और पूरी सिफारिश
  • सहमत। यह Linux के “काम करने के तरीके” के भी थोड़ा खिलाफ़ लगता है
    जैसे Opnsense DHCP वाले हिस्से के लिए dnsmasq और DNS के लिए unbound इस्तेमाल करता है, और यह कुछ “अजीब” लगता है
  • कुछ हद तक यही मकसद है। dnsmasq एक “छोटा router चलाने” वाली app को एक डिब्बे में भर देता है
    DHCP और DNS जुड़े हुए हैं, और PXE को DHCP entries चाहिए। अगर simple setup चाहिए, तो नहीं तो कम से कम 3 daemons को जोड़ना पड़ेगा जिनकी config syntax भी अलग-अलग होगी

• इस क्षेत्र का ज़्यादा अनुभव रखने वालों के लिए एक beginner सवाल है: इस तरह के software को Erlang जैसी garbage collection और concurrency वाली language runtime पर ज़्यादा क्यों नहीं लिखा जाता?

  • dnsmasq की पहली release 2001 में आई थी। उस समय high-performance network server के लिए वास्तव में इस्तेमाल की जा सकने वाली languages की सूची बहुत लंबी नहीं थी, और Erlang उसमें नहीं था
    performance hit बहुत बड़ा था, एक ऐसा opaque runtime था जिसके उस समय stable होने को लेकर भरोसा करना कठिन था, contributors कम थे, और dependency footprint भी बड़ा था जो ज्यादातर systems पर installed नहीं होता था
    करीब 2015 में जब मैंने production systems में Erlang इस्तेमाल किया, तब भी अगर आप उसके मूल design intent से थोड़ा हटते थे, तो rough edges दिखते थे। यह सिर्फ Erlang की आलोचना नहीं, बहुत-सी languages और runtimes में ऐसा था
    आने वाले हफ्तों या महीनों तक impact झेलने वाले ऐसे कई systems की पृष्ठभूमि भी यही है। Linux kernel के लिए उस समय संभावित alternatives लगभग सिर्फ C++ तक सीमित थे। सुरक्षा समस्याओं का स्थायी उदाहरण OpenSSL 1998 में शुरू हुआ था
    “network access वाले नए projects को C में मत लिखो” — इस बात से मैं बहुत मज़बूती से सहमत हूँ, लेकिन अगर 1998 में लौटें तो यह बताना कठिन है कि वास्तव में और कौन-सा विकल्प व्यावहारिक था
    ज़्यादा सुरक्षित languages थीं, लेकिन उनकी communities C की तुलना में बहुत छोटी थीं, और उनकी stability पर भरोसा करना भी कठिन था। Java आ चुका था, लेकिन वह network servers के लिए गंभीर उम्मीदवार कब बना, यह ठीक-ठीक नहीं कह सकता; मेरा अनुमान है कि 2000 के दशक के आख़िर में। 1999 में मैंने जो Java देखा था, वह अभी वहाँ नहीं था
    उदाहरण के लिए, 2011 में मैंने एक अपेक्षाकृत कम महत्वपूर्ण उपयोग के लिए Haskell network server चलाया था, और वह production network के लिए बिल्कुल चरम न माने जाने वाले हालात में गिर गया
    2013 में मैंने वही codebase core execution loop बदले बिना फिर इस्तेमाल किया, और वह लगभग 90% बेहतर था, इसलिए मुझे लगता है कि समस्या मेरी code से ज़्यादा Haskell की तरफ़ थी
    फिर भी वह असली production में डालने लायक नहीं था, लेकिन कम से कम इससे यह दिखा कि विफलता सिर्फ मेरी code की नहीं थी। इसका मतलब यह भी है कि भले Haskell 2000s में मौजूद था, तब भी उसे network server के लिए व्यावहारिक विकल्प मानना कठिन था
    अब पहले की तुलना में कहीं ज़्यादा विकल्प हैं
  • C में आम तौर पर struct को सीधे network packets पर map करना आसान होता है
    दूसरी languages में यह अक्सर इतना सरल नहीं होता
    और हाँ, वे अक्सर ज़्यादा धीमी और ज़्यादा भारी भी होती हैं