90-दिन की disclosure policy खत्म हो चुकी है

 (blog.himanshuanand.com)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 90-दिन की responsible disclosure अब LLM की वजह से खोजकर्ताओं और exploit विकास की गति बढ़ने पर अपना सुरक्षा प्रभाव खो चुकी है
  • 6 हफ्तों में 11 लोगों ने वही critical payment verification bug रिपोर्ट किया, जिससे simultaneous rediscovery साफ़ दिखी
  • React patch diff को AI की मदद से सिर्फ़ 30 मिनट में working exploit में बदला गया
  • Copy Fail और Dirty Frag public PoC और real-world exploitation तक पहुँचे, जिससे embargo टूट गया
  • critical issues को P0 की तरह तुरंत handle करना होगा, और LLM को security pipeline में शामिल करना होगा

90-दिन के responsible disclosure model के टूटने की पृष्ठभूमि

  • 90-दिन की responsible disclosure window ऐसे माहौल के लिए बनाई गई थी जहाँ bug खोजने वाले कम होते थे और exploit development धीमा होता था
  • पिछले 12 महीनों में defenders, attackers और researchers द्वारा इस्तेमाल किए जाने वाले tools लगभग समान गति से अधिक सक्षम हुए हैं, और आकलन यह है कि LLM ने vulnerability discovery और exploit development का समय लगभग 0 के करीब ला दिया है
  • 2019-शैली के model में Google Project Zero की तरह vendor को 90 दिन दिए जाते थे, और उस दौरान ये मान्यताएँ रहती थीं
    • वही bug किसी और को लगभग नहीं मिलेगा
    • किसी और को मिले भी तो समय लगेगा
    • vendor को patch लिखने के लिए पर्याप्त head start मिलेगा
    • patch public होने के बाद attacker को इसे reverse engineer करके working exploit बनाने में कई दिन या हफ्ते लगेंगे
  • ये सारी मान्यताएँ अब गलत साबित हो चुकी हैं, और 90-दिन की window अब users की रक्षा करने के बजाय उन लोगों को 90 दिनों की head start देती है जिनके पास bug पहले से मौजूद है

केस 1: 6 हफ्तों में 11 लोगों ने वही critical bug रिपोर्ट किया

  • अप्रैल के अंत में एक कंपनी को एक गंभीर bug रिपोर्ट किया गया, लेकिन triage team ने जवाब दिया कि यह पहली बार मार्च में रिपोर्ट हुआ था और रिपोर्ट करने वाला व्यक्ति 11वाँ submitter था
  • bug का स्वरूप यह था कि वेबसाइट पर सामान खरीदने के बाद attacker server को अपनी तरफ़ से बदला हुआ response वापस भेज सकता था, और क्योंकि response के लिए signature verification नहीं थी, server उसे वैध मान लेता था
    • उदाहरण के लिए 5,000 डॉलर की चीज़ 0 डॉलर में खरीदी जा सकती थी, या वास्तविक भुगतान के बिना purchase को complete दिखाया जा सकता था
  • लगभग 6 हफ्तों में 11 अलग-अलग लोगों द्वारा वही critical bug खोज लिया जाना दिखाता है कि LLM-assisted hunters लगभग एक ही समय में समान vulnerabilities पर converge कर रहे हैं
  • BlueWater CTF के एक परिचित ने कुछ महीने पहले ही यह बात उठाई थी कि आपस में असंबंधित reporters और workflows, LLM की मदद से, एक ही bug तक पहुँच रहे हैं
  • triage पक्ष ने भी यही पैटर्न देखा
    • @d0rsky ने लिखा कि नए vulnerability pattern के सामने आते ही, LLM prompts, skills और automation की मदद से कुछ ही दिनों में उसी root cause पर duplicate reports की बाढ़ आ जाती है
    • अगर researchers इतनी तेज़ी से इसे reproduce कर सकते हैं, तो patch से पहले black hats भी ऐसा कर सकते हैं, यह चिंता बढ़ती है
  • अगर 10 लोगों ने रिपोर्ट किया है, तो ऐसे लोग भी हो सकते हैं जिन्होंने रिपोर्ट नहीं किया, और वही LLM सिर्फ़ अच्छे researchers के लिए नहीं बल्कि किसी के लिए भी उपलब्ध है
  • CVE credit और bug bounty सिर्फ़ एक व्यक्ति को मिलते हैं, इसलिए बाकी 9 लोग या जिन्होंने शुरुआत में रिपोर्ट ही नहीं किया, वे 90-दिन की घड़ी से बंधे नहीं हैं
  • इस स्थिति में 90-दिन की disclosure window users की रक्षा नहीं करती, बल्कि उन लोगों को समय देती है जिनके पास bug पहले से है

केस 2: React patch से working exploit तक 30 मिनट

  • React ने कई security issues के लिए patches जारी किए और public blog post प्रकाशित की
  • एक local test app के लिए patch पढ़कर working exploit बनाने में सिर्फ़ 30 मिनट लगे
  • public issue denial of service (DoS) था, और AI ने diff समझने, vulnerable code path पहचानने और PoC लिखने का अधिकांश काम किया
  • पहले public patch को working n-day exploit में बदलने के लिए skilled reverse engineers को कई दिन से लेकर कई हफ्ते लगते थे, और यही time gap admins को update करने का safety buffer देता था
  • अब साधारण bugs कुछ मिनटों में और जटिल bugs कुछ घंटों में exploit हो सकते हैं, और skilled reverse engineer अब अनिवार्य नहीं रहा
  • अब यह मानकर चलना होगा कि patch आते ही exploit भी मौजूद है, और अगले maintenance window तक deployment टालना उचित नहीं है

केस 3: Linux kernel में लगातार आए Copy Fail और Dirty Frag

  • पिछले 2 हफ्तों में Linux kernel में लगातार दो critical vulnerabilities सामने आईं, दोनों के public exploits थे और दोनों ने major distributions को प्रभावित किया

  • Copy Fail

    • 29 अप्रैल को Xint Code ने Copy Fail public किया
    • Xint Code, Theori के पीछे की टीम है, और इसे DEF CON CTF 9 बार जीतने वाली टीम के रूप में पेश किया गया
    • Copy Fail, CVE-2026-31431 है, और इसे kernel crypto subsystem में एक सीधा logic flaw बताया गया
    • कहा गया कि यह race condition के बिना 100% reliable है, और 732-byte Python script से 2017 के बाद जारी लगभग सभी Linux distributions पर root privileges मिल सकते हैं
    • Ubuntu, RHEL, Amazon Linux, SUSE जैसी major distributions प्रभावित थीं
    • AI की मदद से kernel के crypto/ subsystem को लगभग 1 घंटे तक auto-scan करके इसे खोजा गया, और कहा गया कि vulnerability 9 साल से exposed थी
    • technical analysis Xint की पोस्ट में है
    • mainline commit a664bf3d603d से patch आया, और algif_aead module disable करना एक mitigation था
    • बाद में यह भी कहा गया कि Iranian attackers ने इस vulnerability का इस्तेमाल करके Ubuntu servers compromise किए और उन्हें DDoS campaign nodes में बदला
    • AI से खोजी गई kernel privilege escalation vulnerability को public PoC से nation-state attackers द्वारा weaponize किए जाने तक पहुँचने में सिर्फ़ कुछ दिन लगे

  • Dirty Frag

    • लगभग एक हफ्ते बाद, 7 मई को Hyunwoo Kim(@v4bel) ने Dirty Frag public किया
    • Dirty Frag, CVE-2026-43284 और CVE-2026-43500 को chain करने वाली vulnerability है
    • यह kernel के IPSec ESP (esp4/esp6) और RxRPC networking modules की दो vulnerabilities को जोड़ती है
    • यह Copy Fail और Dirty Pipe जैसे bug families की तरह ही page-cache corruption technique इस्तेमाल करती है, लेकिन attack path अलग है
    • Copy Fail mitigation लागू होने पर भी Dirty Frag काम करता है
      • algif_aead को blacklist करने पर भी Dirty Frag उस module का उपयोग नहीं करता
    • कहा गया कि यह unprivileged user से deterministically root तक escalate कर सकता है, और Ubuntu, RHEL 10.1, openSUSE, CentOS Stream, AlmaLinux, Fedora 44 जैसी major distributions पर काम करता है
    • compile और run एक single-line command से संभव है

  • Dirty Frag disclosure process और embargo का टूटना

    • Hyunwoo Kim ने 29–30 अप्रैल को [email protected] पर रिपोर्ट किया और patch public submission के रूप में भेजा
    • 7 मई को linux-distros mailing list के साथ coordination हुआ और 5-दिन का embargo तय हुआ
    • उसी दिन कुछ घंटों के भीतर एक असंबंधित third party ने ESP vulnerability की detailed exploit जानकारी public कर दी, जिससे embargo टूट गया
    • distribution maintainers से चर्चा के बाद, Hyunwoo ने Dirty Frag का पूरा analysis, exploit code और working PoC public कर दिया
    • उस समय तक कोई भी Linux distribution patch उपलब्ध नहीं करा रही थी
    • वर्तमान स्थिति में CVE-2026-43284, यानी ESP पक्ष, के लिए mainline fix है, लेकिन CVE-2026-43500, यानी RxRPC component, के लिए अभी upstream patch नहीं है
    • Ubuntu, Red Hat, और Tenable ने अपनी advisories जारी कीं

  • Dirty Frag का वास्तविक दुरुपयोग

    • Microsoft Defender team ने public होने के 24 घंटों के भीतर सीमित वास्तविक exploitation confirm किया
    • कहा गया कि attackers ने SSH access हासिल किया, ELF binaries deploy किए, su से root privileges लिए, authentication settings बदलीं, session files हटाईं, और lateral movement किया
    • CTS(@gf_256) ने इसे “responsible disclosure is dead🤦” कहकर संक्षेप में बताया

वास्तव में क्या खत्म हो चुका है

  • 90-दिन की disclosure window कोई ऐसा model नहीं है जिसे सुधारा जा सके; यह अब समाप्त हो चुका है
  • यह model उस दुनिया के लिए था जहाँ खोजकर्ता कम थे और exploit development धीमा था, लेकिन LLM ने खोजकर्ताओं की संख्या बढ़ा दी और exploit development तेज़ कर दिया
  • अगर 10 असंबंधित लोग 6 हफ्तों में वही bug खोज लेते हैं, और AI patch diff को 30 मिनट में working exploit में बदल सकता है, तो 90-दिन की window किसी की रक्षा नहीं करती
  • Copy Fail में AI scanning से public PoC और nation-state weaponization तक की यात्रा कुछ ही दिनों में हो गई
  • Dirty Frag में वही bug family independently खोजने वाले third party की वजह से embargo कुछ घंटों में टूट गया
  • ऐसे माहौल में, जहाँ कई researchers और AI tools एक ही vulnerability को एक साथ independently rediscover कर रहे हों, coordinated disclosure बनाए रखना मुश्किल है
  • monthly patch cycle भी खत्म हो चुकी है
    • vulnerability और fix के बीच 30-दिन की window इस धारणा पर बनी थी कि attackers release train से धीमे होंगे
    • जब Microsoft ने Dirty Frag के लिए 24 घंटों में वास्तविक exploitation देख लिया, तो monthly maintenance window safety margin नहीं बल्कि attack window बन गई
  • advisory का इंतज़ार करने का तरीका भी खत्म हो चुका है
    • जब defender CVE description पढ़ रहा होता है, attacker git log --diff-filter=M पढ़ रहा होता है
    • advisory एक downstream output है, जबकि patch diff ही असली signal है

उद्योग को क्या बदलना चाहिए

  • निष्कर्ष यह है कि सभी critical security issues को P0 की तरह देखकर तुरंत ठीक करना होगा
  • “24 घंटे में”, “अगले sprint में”, “impact assessment के बाद” नहीं, बल्कि चल रहा काम रोककर तुरंत fix करने का स्तर चाहिए
  • production deployment जटिल हो सकता है और change management की ज़रूरत हो सकती है, लेकिन threat landscape change management process का इंतज़ार नहीं करता

  • Vendor

    • critical bug report आते ही समय चलना शुरू हो जाता है
    • triage पूरा होने या engineering को handoff होने का समय नहीं, बल्कि report आने का क्षण आधार होना चाहिए
    • अगर किसी ने रिपोर्ट किया है, तो मान लेना चाहिए कि 10 लोगों के पास वह पहले से है और उनमें कम-से-कम 1 व्यक्ति friendly नहीं है

  • Researchers

    • critical bugs को लंबे समय तक hold न करें, और जितनी छोटी disclosure window संभव हो उतनी छोटी window के लिए दबाव डालें
    • अगर vendor 1 हफ्ते में fix नहीं कर सकता, तो यह disclosure problem नहीं बल्कि vendor problem है
    • पहले “समय देना” शिष्टाचार था क्योंकि संभावना रहती थी कि आप अकेले finder हैं, लेकिन अब यह संभावना कम है

  • Vulnerability management

    • vulnerability management real-time होना चाहिए
    • “weekly scan, sprint में triage, cycle के अनुसार patch” वाली प्रक्रिया उस timeline की है जिसमें attacker पहले ही आगे निकल चुका है
    • critical issues के लिए नया maximum response time दिनों में नहीं बल्कि घंटों में है, और वह भी शायद धीमा हो

Blue team को LLM को defense pipeline में क्यों शामिल करना चाहिए

  • attackers पहले ही LLM को exploit pipeline में integrate कर चुके हैं, और defense side को भी उसी गति से चलना होगा
  • code push के समय LLM को integrate करना होगा
    • हर pull request, merge और deploy पर AI-assisted security review को CI pipeline के हिस्से के रूप में चलाना चाहिए
    • इसे linter और unit test की तरह push के समय चलना चाहिए, न कि quarterly audit या postmortem review की तरह
    • vulnerabilities को production तक पहुँचने से पहले पकड़ना होगा, और PR review में fix करने की लागत CVE public होने के बाद fix करने से बहुत कम होती है
  • patch analysis में भी LLM को integrate करना होगा
    • जब upstream dependency security patch जारी करे, तो pipeline को automatically diff लाना, change analyze करना, अपने codebase पर उसका प्रभाव जाँचना, और flag raise करना चाहिए
    • यह public repository में patch आते ही मिनटों के भीतर अपने-आप होना चाहिए, न कि इस पर निर्भर रहे कि कोई mailing list पढ़े और Jira ticket खोले
    • अगर Xint Code ने 1 घंटे की auto-scan से Copy Fail खोज लिया, तो अपनी dependencies को भी उसी तरह scan करना चाहिए
  • dependency scanning में भी LLM का उपयोग होना चाहिए
    • supply chain उतनी ही मज़बूत है जितनी उसकी सबसे कमज़ोर transitive dependency
    • AI-based dependency scanner dependency tree में vulnerability impact trace कर सकता है, affected versions mark कर सकता है, और upgrade path भी सुझा सकता है
    • इसे weekly नहीं बल्कि लगातार चलना चाहिए
  • patch release से पहले AI से patch test करना चाहिए
    • अगर React case की तरह LLM 30 मिनट में patch को exploit में बदल सकता है, तो defenders को patch public होने से पहले उसी tool से validation करनी चाहिए
    • यह सुनिश्चित करना होगा कि patch वास्तव में समस्या ठीक कर रहा है और कोई नई समस्या नहीं बना रहा
    • इसे regression tests generate करने और यह देखने के लिए इस्तेमाल करना चाहिए कि वही pattern codebase के अन्य हिस्सों में तो नहीं है
  • “vulnerability exists” और “vulnerability exploited” के बीच की window लगभग 0 होती जा रही है, और defense side को भी attack side की ही तरह automate करना होगा
  • अधिक zero-days अधिक तेज़ी से real-world environments में exploit होंगे, और इसके कारण वही tools, कम हुई entry barrier, बढ़े हुए खोजकर्ता, और सिकुड़ी हुई timelines हैं
  • इस बदलाव में वही teams टिकेंगी जो मजबूरी आने से पहले AI को अपनी security pipeline का first-class component बना लेंगी

निष्कर्ष

  • Dirty Frag advisory पढ़ने वाला system administrator, जिसके पास patch नहीं है, exploit पहले से public है, Microsoft ने वास्तविक exploitation देख ली है, mitigation सिर्फ़ IPSec module disable करना है, और उसे 400 servers संभालने हैं — यही नई baseline बन चुकी है
  • 90-दिन की disclosure policy, monthly patch cycle, और disclosure और exploitation के बीच समय होने की धारणा — ये सब खत्म हो चुके हैं
  • अब जो बचा है वह है तेज़ी से चलने, मज़बूत automation करने, और critical bugs को वास्तविक emergency की तरह treat करने की क्षमता
  • जिस AI wave ने पुराने model को तोड़ा, वही तेज़ patching, automated scanning, real-time threat intelligence, और AI-assisted code review जैसे नए model भी संभव बनाती है
  • tools पहले से मौजूद हैं; असली सवाल यह है कि defenders उन्हें attackers से पहले इस्तेमाल करेंगे या नहीं, और फिलहाल इस race में attackers आगे हैं

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

1 टिप्पणियां

 
GN⁺ 3 시간 전
Lobste.rs की राय

  • मन मारकर सहमत होना पड़ रहा है। हमारी कंपनी में भी इस विषय पर जांच की गई थी, और patch से exploit तक पहुंचने में लगने वाला समय लगभग तुरंत जैसा है

  • responsible disclosure नीति शुरू से ही एक ऐसी कल्पना थी जिस पर लोग आपसी शिष्टाचार के नाते भरोसा करने का दिखावा करते थे। यह मूल रूप से माहौल के हिसाब से चलने वाली चीज़ थी, और LLM-आधारित vulnerability discovery tools ने बस इसकी असलियत उजागर कर दी

  • यह बात काफ़ी विडंबनापूर्ण लगती है कि इस लेख में भी LLM द्वारा लिखा गया होने की गंध आती है

    • बात समझ में आती है। अगर कोई मौलिक idea है, तो किसी और के करने से पहले उसे प्रकाशित करना होगा। critical thinking और आत्म-चिंतन मर चुके हैं, और अगर विचार आने के 39 मिनट के भीतर उसे ब्लॉग पर नहीं डाला, तो कोई और आपसे पहले कर देगा :P
    • मुझे ऐसा नहीं लगता। ऐसी writing style LLM से पहले के तकनीकी लेखों में भी बहुत पहले से रही है, और प्रमुख LLM आम तौर पर इस लेख से थोड़ा अलग तरह से लिखते हैं
    • यह डर फैलाने वाले विज्ञापन जैसा पढ़ा जाता है
    • अच्छा हो या बुरा, अब चीज़ें बस इसी तरह आगे बढ़ती हुई लगती हैं

  • शायद जो सचमुच मर गया है, वह mission-critical परिस्थितियों में इस्तेमाल होने वाले हाथ से बने कारीगराना boutique C programs का युग है