Claude Mythos Preview के साथ Firefox को मजबूत बनाने की पर्दे के पीछे की कहानी

 (hacks.mozilla.org)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Mozilla ने model performance में सुधार और harness को बेहतर बनाकर AI-जनित security reports में signal बढ़ाया और noise घटाया, जिससे Firefox में वास्तविक security bugs को बड़े पैमाने पर खोजने वाली pipeline बनाई गई
  • Firefox 150 release में Claude Mythos Preview द्वारा पहचाने गए 271 bugs को ठीक किया गया, और 149.0.2, 150.0.1, 150.0.2 में भी संबंधित fixes शामिल हैं
  • सार्वजनिक किए गए प्रमुख bugs में JIT में WebAssembly GC struct initialization हटने से बना fake object primitive, IPC race condition के जरिए parent process UAF, NaN deserialization issue, XSLT का 20 साल पुराना rehash bug, और rowspan=0 का उपयोग कर 16-bit layout bitfield overflow जैसी समस्याएँ शामिल हैं
  • सार्वजनिक किए गए bugs का बड़ा हिस्सा sandbox escape है, जहाँ compromised content process के privileged parent process तक privilege escalation को मानकर उन attack surfaces को AI analysis ने अधिक व्यापक रूप से कवर किया जिन्हें सिर्फ fuzzing से खोजना कठिन है
  • Mozilla ने मौजूदा fuzzing infrastructure के ऊपर agentic harness जोड़ा, non-reproducible अटकलों को हटाया और test cases के जरिए hypotheses को validate किया; आगे चलकर इसे continuous integration में जोड़कर patches के tree में आते ही scan करने की योजना है

AI model से सामने आए Firefox security bugs में बदलाव

  • कुछ महीने पहले तक open source projects में आने वाली AI-जनित security bug reports अक्सर देखने में विश्वसनीय लगती थीं, लेकिन गलत होती थीं, जिससे maintainers पर asymmetric cost पड़ती थी
  • Firefox में थोड़े समय में स्थिति काफी बदल गई, और इसका मुख्य कारण model performance में सुधार तथा models को harness के जरिए steer, extend और combine कर signal बढ़ाने और noise फ़िल्टर करने की तकनीकों में सुधार था
  • Mozilla आम तौर पर security advisories और fixes जारी होने के बाद भी detailed bug reports को कई महीनों तक private रखता है, लेकिन इस बार पूरे ecosystem में तात्कालिकता और रुचि को देखते हुए कुछ reports सार्वजनिक करने का निर्णय लिया गया
  • सार्वजनिक की गई reports browser के कई subsystems से चुनी गई हैं; चयन कुछ हद तक मनमाना है, लेकिन reports की गहराई और विविधता यह दिखाती है कि defenders को इन तकनीकों को अपनाने की ज़रूरत है

सार्वजनिक किए गए प्रमुख bugs

  • 2024918
    • गलत equality check के कारण JIT ने live WebAssembly GC struct initialization को optimization के तहत हटा दिया, जिससे internal और external researchers की व्यापक fuzzing से गुज़रे code में संभावित arbitrary read/write से जुड़ने वाला fake object primitive बन सकता था
  • 2024437
    • <legend> element का 15 साल पुराना bug, जो recursive stack depth limit, expando properties, cycle collection और browser के अलग-अलग हिस्सों के edge cases को बारीकी से जोड़कर trigger किया गया
  • 2021894
    • IPC race condition का भरोसेमंद exploitation कर compromised content process parent process के IndexedDB reference count को manipulate कर सकता था, जिससे UAF और संभावित sandbox escape हो सकता था
  • 2022034
    • raw NaN IPC boundary पार करते समय tagged JS object pointer जैसा दिख सकता था, जिससे double deserialization parent process में fake object primitive और sandbox escape तक पहुँच सकती थी
  • 2024653
    • nested event loops, pagehide listener और garbage collection को जोड़ने वाले जटिल test case से <object> element के property setter में UAF trigger हुआ
  • 2022733
    • WebTransport में हज़ारों certificate hashes डालकर heavy refcount copy loop में race condition की संभावना बढ़ाई गई, और compromised content process से IPC के जरिए parent UAF trigger किया गया
  • 2023958
    • glibc DNS function calls को intercept कर malicious DNS server simulate किया गया, और UDP से TCP fallback edge case को reproduce कर HTTPS RR और ECH parsing के दौरान buffer over-read और parent process stack memory leak कराया गया
  • 2025977
    • यह XSLT का 20 साल पुराना bug था, जहाँ re-entrant key() call hash table rehash trigger कर backing store को free कर देता था, लेकिन raw entry pointer का उपयोग जारी रहता था; यह ठीक की गई कई sec-high XSLT समस्याओं में से एक था
  • 2027298
    • color picker को patch कर automate करना कठिन user selection simulate किया गया, फिर synchronous input events से nested event loop चलाकर actor teardown में re-enter किया गया और callback को free होते समय release कराया गया, जिससे content process UAF हुआ
  • 2023817
    • compromised content process parent process में arbitrary wallpaper image decode कराने के लिए भेज सकता था, और hypothetical image decoder vulnerability के साथ मिलकर यह sandbox escape तक जा सकता था
    • इसके लिए parent process में input की trust level तय करने वाला ऐसा inference चाहिए था जिसे automate करना कठिन था
  • 2029813
    • Firefox 95 की fine-grained sandboxing तकनीक RLBox में untrusted side से trusted side पर values copy करने वाली validation logic की कमी का उपयोग कर sandbox bypass किया गया
  • 2026305
    • HTML table में rowspan=0 के विशेष अर्थ का उपयोग करने वाले बहुत छोटे test case ने >65535 rows जोड़कर clamping bypass किया और 16-bit layout bitfield को overflow किया; यह bug कई वर्षों तक fuzzers से नहीं पकड़ा गया

Sandbox escape और defense layers

  • सार्वजनिक किए गए bugs का बड़ा हिस्सा sandbox escape है, और Firefox की पूरी compromise chain तक पहुँचने के लिए इन्हें अन्य exploits के साथ जोड़ना पड़ता है
  • ऐसी reports यह मानकर चलती हैं कि site content render करने वाला sandboxed process किसी अलग bug से पहले ही compromised है, और attacker-controlled machine code privileged parent process तक privilege escalation की कोशिश कर रहा है
  • sandbox escape बनाते समय model Firefox source code को patch कर सकता है, बशर्ते modified code केवल sandbox process के भीतर चले
  • इस प्रकार के bugs को fuzzing से खोजना कठिन है; Mozilla ने snapshot-based IPC fuzzing जैसी तकनीकें विकसित की हैं, लेकिन AI analysis इस महत्वपूर्ण surface को कहीं अधिक व्यापक रूप से कवर कर सका
  • model जिन चीज़ों को नहीं खोज पाया, वे भी महत्वपूर्ण थीं
    • हाल के वर्षों में security researchers ने privileged parent process में prototype pollution trigger कर process sandbox से बाहर निकलने वाली कई reports भेजी थीं
    • Mozilla ने समस्याओं को एक-एक करके ठीक करने के बजाय, default रूप से prototype को freeze करने वाला architectural change लागू किया
    • harness logs में इस escape path को आज़माने के कई संकेत दिखे, लेकिन design ने उसे रोक दिया, जिससे पहले किए गए hardening work का सीधा असर स्पष्ट हुआ

Harness के साथ security hardening pipeline बनाना

  • Mozilla ने पिछले कुछ वर्षों में GPT 4 और Sonnet 3.5 जैसे models से high-risk code का static analysis करने वाले LLM code auditing experiments अंदरूनी तौर पर चलाए थे
  • शुरुआती experiments ने संभावना दिखाई, लेकिन false positive ratio ऊँचा होने से इन्हें बड़े पैमाने पर ले जाना कठिन था
  • security issues को भरोसेमंद ढंग से detect करने वाले agentic harness के आने से स्थिति बदली
    • वास्तविक bugs खोजे जा सकते हैं
    • reproduce न होने वाली अटकलों को हटाया जा सकता है
    • सही interface और instructions मिलने पर reproducible test cases बनाए और चलाए जा सकते हैं, ताकि code bug hypotheses को dynamic तरीके से validate किया जा सके
  • Mozilla ने फरवरी में Anthropic द्वारा भेजे गए शुरुआती issues को ठीक करने के बाद, मौजूदा fuzzing infrastructure के ऊपर अपना harness बनाया
  • शुरुआत में Claude Opus 4.6 के साथ sandbox escape खोजने के लिए छोटे पैमाने का experiment शुरू किया गया
    • सिर्फ इस model ने भी multiprocess browser engine code पर complex reasoning की ज़रूरत वाले कई पहले-अज्ञात vulnerabilities की पहचान की
    • शुरू में terminal में प्रक्रिया को सीधे देखते हुए prompts और logic को real time में adjust किया गया
    • काम स्थिर होने के बाद कई ephemeral VMs में tasks parallelize किए गए, और हर VM किसी खास target file में bug मिलने पर result को bucket में लिखता था
  • सिर्फ discovery subsystem पर्याप्त नहीं था
    • क्या खोजना है, कहाँ देखना है, और outputs को कैसे handle करना है, यह सब शामिल करते हुए पूरे security bug lifecycle के साथ integration ज़रूरी था
    • इसमें existing issues के साथ deduplication, bug tracking, triage और fixes की shipping भी शामिल थी
    • model harness को चलाने वाला मुख्य primitive है, लेकिन इसे बड़े पैमाने पर उपयोगी बनाने के लिए पूरी pipeline चाहिए
  • harness को projects के बीच दोबारा उपयोग किया जा सकता है, लेकिन pipeline codebase के semantics, tools और process के अनुसार project-specific होती है
  • Firefox engineers द्वारा आने वाले bugs को संभालने की प्रक्रिया के साथ एक क़रीबी feedback loop रखा गया, और इसके लिए काफ़ी iteration की ज़रूरत पड़ी

Claude Mythos Preview और model replacement का प्रभाव

  • end-to-end pipeline तैयार हो जाने पर नया model आने पर उसे दूसरे model से बदलना आसान हो जाता है
  • Mozilla ने public models से भी कई गंभीर bugs खोजे, और इसी pipeline की वजह से Claude Mythos Preview को evaluate करने का मौका मिलते ही उसे तुरंत इस्तेमाल किया जा सका
  • model upgrade ने पूरी pipeline की effectiveness बढ़ा दी
    • संभावित bugs बेहतर ढंग से खोजे गए
    • bugs को साबित करने वाले proof-of-concept test cases बेहतर बने
    • failure modes और impact को बेहतर ढंग से summarize किया गया
  • Firefox 150 release में Claude Mythos Preview द्वारा पहचाने गए 271 bugs को ठीक करने के अलावा, 149.0.2, 150.0.1, 150.0.2 में भी संबंधित fixes शामिल हैं
  • अंदरूनी तौर पर bugs खोजने के अन्य तरीके भी जारी रहे, और अन्य projects की तरह हाल के महीनों में external reports भी काफी बढ़ीं
  • हर bug को ठीक से ठीक करने के लिए बारीक ध्यान की ज़रूरत थी, और अभूतपूर्व scale को संभालने के लिए पिछले कुछ महीनों में बहुत काम और लंबे घंटे लगे
  • 100 से अधिक लोगों ने सबसे सुरक्षित Firefox जारी करने के लिए code contributions में हिस्सा लिया; patch writing और review के अलावा pipeline बनाना और scale करना, triage, fix testing और हर bug की release process management भी की गई

मुख्य सीख

  • software बनाने वाला कोई भी व्यक्ति आज modern models और harness का उपयोग कर bugs खोज सकता है और code को मजबूत बना सकता है
  • शुरुआत simple prompt से की जा सकती है, फिर observe और iterate किया जा सकता है
    • शुरुआती prompt इस वीडियो में दिखाए गए तरीके से बहुत अलग नहीं था
    • iterations के साथ pipeline optimization और scaling के लिए काफी orchestration और tools जोड़े गए, लेकिन inner loop का मूल यही था: “इस code हिस्से में bug है, उसे खोजो और test case बनाओ”
  • Firefox में सभी संभावित bugs समाप्त हो चुके हैं, Mozilla ऐसा दावा नहीं करता, लेकिन मौजूदा trajectory से संतुष्ट है
  • अभी scanning ज़्यादातर human judgment और automatic signals के मिश्रण से चुने गए खास code areas, यानी files और functions, पर केंद्रित है
  • निकट भविष्य में इस analysis को continuous integration system में जोड़कर patch के tree में आते ही scan करने की योजना है
  • models दिए गए context format के प्रति काफ़ी flexible हैं, और उम्मीद है कि patch-based scanning, file-based scanning जितनी या उससे बेहतर काम करेगी
  • यह समय जोखिमभरा है, लेकिन अवसर भी बड़े हैं, और internet को सुरक्षित बनाने के लिए मिलकर काम करना होगा

अक्सर पूछे जाने वाले सवाल

  • “271 bugs” और security advisory numbers अलग क्यों हैं

    • security advisory webpage में internally reported bugs को कई bugs के समूह वाले “rollup” CVEs में group किया जाता है
    • यह webpage CVE assignment के औपचारिक स्रोत foundation-security-advisories repository के yaml से बनाई जाती है
    • कुछ browsers internal findings के लिए CVE identifiers जारी नहीं करते, लेकिन Mozilla यथासंभव पारदर्शिता बनाए रखने के लिए इन्हें सार्वजनिक करता है
    • Firefox 150 में 3 internal rollups थे
      • CVE-2026-6784: 154 bugs
      • CVE-2026-6785: 55 bugs
      • CVE-2026-6786: 107 bugs
    • इन तीन internal rollups का कुल 316 bugs होता है, जो Claude Mythos Preview से खोजे गए घोषित 271 bugs से अधिक है
    • वजह यह है कि Mozilla security team हर दिन Firefox पर attack करती है और नए bugs खोजती है, और उसके तरीके fuzzing systems, manual inspection और कई models का उपयोग करने वाली नई agentic pipeline का संयोजन हैं
    • अप्रैल release में कुल 423 security bugs ठीक किए गए
      • दो हफ़्ते पहले घोषित 271 bugs
      • external reports से आए 41 bugs
      • बाकी 111 bugs internal findings थे, जो मोटे तौर पर तीन श्रेणियों में आते हैं
        • इस pipeline में Claude Mythos Preview का उपयोग कर खोजे गए, लेकिन Firefox 150 के बजाय किसी अन्य release में ठीक किए गए bugs
        • इस pipeline में दूसरे models से खोजे गए bugs
        • fuzzing जैसी दूसरी तकनीकों से खोजे गए bugs
    • Anthropic को इस ताज़ा काम से अलग सीधे 3 CVEs का credit दिया गया
      • CVE-2026-6746
      • CVE-2026-6757
      • CVE-2026-6758
    • ये वे bug fixes हैं जो कुछ महीने पहले Anthropic Frontier Red Team ने Mozilla को भेजे थे, और सामान्य प्रक्रिया के अनुसार हर एक को अलग CVE मिला

  • Security severity ratings का मतलब

    • Mozilla bug urgency बताने के लिए security severity ratings का उपयोग critical से low तक करता है
    • sec-critical और sec-high उन vulnerabilities के लिए होते हैं जिन्हें website visit जैसी सामान्य user action से trigger किया जा सकता है
    • sec-critical और sec-high के बीच तकनीकी अंतर नहीं है, लेकिन sec-critical केवल उन issues के लिए उपयोग होता है जो publicly disclosed हों या real-world attacks में exploit किए गए हों
    • sec-moderate उन vulnerabilities के लिए होता है जिन्हें मूलतः sec-high माना जाता, लेकिन victim से असामान्य और जटिल steps की आवश्यकता होती है
    • sec-low उन परेशान करने वाले bugs के लिए होता है जो safe crash जैसी स्थिति हों और user harm से काफ़ी दूर हों
    • Firefox 150 में घोषित 271 bugs की ratings इस प्रकार थीं
      • sec-high 180
      • sec-moderate 80
      • sec-low 11
    • Mozilla critical/high bugs को सबसे अधिक महत्व देता है, लेकिन correctness issues को ठीक करने और defense in depth के लिए moderate और low security bugs को प्राथमिकता देना भी सामान्य है

  • sec-high या sec-critical और वास्तविक exploit के बीच अंतर

    • sec-high या sec-critical bug का मतलब यह नहीं कि वह तुरंत व्यावहारिक exploit है
    • अधिकांश मामलों में एक critical/high bug अकेले Firefox को compromise करने के लिए पर्याप्त नहीं होता
    • Firefox में defense-in-depth architecture है; उदाहरण के लिए JIT bug exploit होने पर भी सामान्यतः sandboxed और site-isolated process में remote code execution तक ही बात पहुँचती है
    • वास्तविक attackers आम तौर पर कई exploits को chain में जोड़ते हैं ताकि एक या अधिक sandboxing layers और ASLR जैसी OS-level mitigations को पार कर privilege escalation कर सकें
    • Mozilla आम तौर पर यह जाँचने के लिए exploits नहीं बनाता कि bug वास्तविक attackers के लिए उपयोगी होगा या नहीं
    • sec-high classification AddressSanitizer द्वारा रिपोर्ट किए गए use-after-free या out-of-bounds memory issues जैसे अनुमानित crash symptoms पर आधारित होती है
    • threat model यह मानकर चलता है कि पर्याप्त प्रयास के साथ ऐसे bugs exploitable हो सकते हैं
    • यह तरीका exploitability analysis में false negatives का जोखिम घटाता है और अधिक vulnerabilities खोजने व ठीक करने पर resources केंद्रित करने में मदद करता है

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

1 टिप्पणियां

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

  • काश वे इस काम में इस्तेमाल किए गए prompts और दूसरी features भी साझा करते
    अगर bug report या fix history में prompts शामिल किए जाएँ तो इसे दोहराना आसान होगा
    उन्होंने non-Mythos models का भी ज़िक्र किया है, इसलिए लगता है कि इस काम का कुछ हिस्सा दूसरे लोगों के लिए भी तुरंत उपयोगी हो सकता है

    • ज़्यादातर projects में entry barrier सच में बहुत कम है
      मूल रूप से आप बस इतना कहते हैं: “इस project को security issues के नज़रिए से review करो, (파일) से शुरू करो और सभी संभव paths की सूची बनाओ”, फिर हर item के लिए आगे कहते हैं: “इस report को verify करो और proof of concept बनाओ”
      अभी Opus के साथ इस तरीके से कुछ न ढूँढ पाना, कुछ ढूँढ लेने से ज़्यादा मुश्किल है
    • क्या आपको लगता है कि prompt सिर्फ “इस codebase में security vulnerabilities ढूँढो” से ज़्यादा कुछ होगा?

  • कुछ भी कहो, यह सच में प्रभावशाली है
    Mythos से 271 security issues मिले, और कुल मिलाकर 423 मिले
    इनमें से 180 high severity के थे, और कुछ security issues 20 साल पुराने थे

    • यह पूरी तरह साफ़ नहीं है कि Opus 4.6 / Mythos comparison कितना fair था
      इससे ऐसा संकेत मिलता है जैसे Mythos ने उसी code पर, जिसे पहले 4.6 से scan किया गया था, “271 bugs” ढूँढे, लेकिन लेख में यह बात बिल्कुल उसी तरह नहीं कही गई है
      यह भी जानने की जिज्ञासा है कि क्या research harness में भी उसी समय बदलाव हुए थे

  • “हमने जिन कई sec-high issues को ठीक किया, उनमें से एक XSLT से जुड़ा था” वाला हिस्सा शायद XSLT हटाने की बहस की वजह से डाला गया लगता है

  • यहाँ मेरी सबसे बड़ी जिज्ञासा यह है कि false positives कितने report किए गए
    क्या model ने संभावित vulnerabilities लगभग दोगुनी संख्या में report की थीं, और यहाँ जो दिखाया गया है क्या वे सिर्फ verified मामले हैं
    यह भी स्पष्ट नहीं है कि model report करने से पहले reproduction भी करता है या नहीं
    public issues को देखें तो reproduction की कोशिश करते हुए comments दिखते हैं, लेकिन संभव है कि वह कोई पहले से मौजूद bot करता हो
    मुझे यह भी ठीक से नहीं पता कि Firefox पहले इस तरह के काम को कैसे संभालता था, या अब AI के साथ इसे कैसे करता है, इसलिए इस पर थोड़ा और विस्तार बहुत दिलचस्प होगा