parser के अंतर का उपयोग कर SAML SSO authentication bypass तकनीक

 (github.blog)
1 पॉइंट द्वारा GN⁺ 2025-03-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ruby-saml 1.17.0 और उससे पहले के संस्करणों में पाए गए CVE-2025-25291 और CVE-2025-25292 केवल एक वैध signature के जरिए किसी भी उपयोगकर्ता के रूप में login संभव बनाते हैं, जिससे SAML SSO वातावरण में account takeover का जोखिम बढ़ जाता है
  • यह vulnerability signature verification path में REXML और Nokogiri द्वारा एक ही XML document के अलग-अलग Signature elements को अलग तरह से parse करने वाले parser अंतर से उत्पन्न होती है
  • SignedInfo, SignatureValue, assertion hash, और DigestValue अलग-अलग parser results से मिलकर जुड़ सकते हैं, जिससे हर check pass हो जाता है लेकिन hash और signature के बीच का संबंध टूट सकता है
  • GitHub ने ruby-saml को फिर से अपनाने की समीक्षा के दौरान bug bounty और Security Lab review चलाया, GitLab में exploit किए जा सकने वाले instances खोजे और security team को सूचित किया; वर्तमान में GitHub authentication में ruby-saml का उपयोग नहीं करता
  • उपयोगकर्ताओं को ruby-saml 1.18.0 पर update करना चाहिए, और omniauth-saml जैसी ruby-saml पर निर्भर libraries को भी ऐसे release पर upgrade करना चाहिए जो patched version को reference करता हो

ruby-saml authentication bypass का प्रभाव

  • ruby-saml 1.17.0 और उससे पहले के संस्करणों में उच्च-गंभीरता वाली authentication bypass vulnerabilities की 2 घटनाएँ पुष्टि हुईं
    • CVE-2025-25291
    • CVE-2025-25292
  • यदि attacker के पास target organization के SAML response या assertion verification में इस्तेमाल होने वाली key से बना एक वैध signature हो, तो वह सीधे SAML assertion बनाकर किसी भी user के रूप में login कर सकता है
  • संभावित signature स्रोत निम्न हो सकते हैं
    • कम privileges वाले किसी दूसरे user का signed assertion या response
    • कुछ मामलों में publicly accessible SAML IdP का signed metadata
  • अंततः इस vulnerability का उपयोग account takeover attack में किया जा सकता है
  • GitHub अभी authentication के लिए ruby-saml का उपयोग नहीं करता, लेकिन SAML authentication में open source library को फिर से अपनाने के विकल्प की समीक्षा करते समय उसने ruby-saml का मूल्यांकन किया
  • ruby-saml अन्य लोकप्रिय projects और products में भी उपयोग होता है, और GitHub ने GitLab में exploit किए जा सकने वाले instances खोजकर GitLab security team को सूचित किया

GitHub ने ruby-saml की फिर से समीक्षा क्यों की

  • GitHub 2014 तक ruby-saml का उपयोग करता था, लेकिन उस समय आवश्यक features की कमी के कारण उसने अपनी स्वयं की SAML implementation पर switch किया
  • बाद में उसकी अपनी implementation में भी encrypted assertion से संबंधित vulnerabilities पर bug bounty reports आईं, जैसे CVE-2024-9487, और GitHub ने ruby-saml को फिर से अपनाने पर विचार शुरू किया
  • अक्टूबर 2024 में ahacker1 द्वारा खोजी गई ruby-saml authentication bypass vulnerability CVE-2024-45409 सार्वजनिक हुई
  • GitHub ने ruby-saml migration की संभावना का अधिक बारीकी से मूल्यांकन करने के लिए private bug bounty शुरू की
    • चुने गए researchers को ruby-saml के साथ SAML authentication करने वाले GitHub test environment का access दिया गया
    • GitHub Security Lab ने भी ruby-saml के attack surface की साथ में समीक्षा की

दो XML parsers से बनी verification mismatch

  • code review के दौरान ahacker1 और GitHub Security Lab ने पुष्टि की कि ruby-saml के signature verification path में दो XML parsers साथ उपयोग किए जाते हैं
    • REXML: pure Ruby में implement किया गया XML parser
    • Nokogiri: libxml2, libgumbo, और JRuby के लिए Xerces आदि को wrap करने वाला API, जो XML और HTML parsing को support करता है
  • समस्या वाला path xml_security.rb की validate_signature method है
  • यह method पहले Signature element और वास्तविक SignatureValue को REXML से पढ़ती है
    • REXML::XPath.first(@working_copy, "//ds:Signature", {"ds"=>DSIG})
  • वहीं उसी verification flow में Signature और SignedInfo को Nokogiri से फिर query और canonicalize किया जाता है
    • document.at_xpath('//ds:Signature', 'ds' => DSIG)
    • noko_signed_info_element.canonicalize(canon_algorithm)
  • assertion को Nokogiri से extract, canonicalize, और hash किया जाता है, लेकिन comparison target DigestValue REXML से आता है
  • अंतिम verification material इस तरह विभाजित हो जाता है
    • assertion Nokogiri से extract और canonicalize होने के बाद hash किया जाता है
    • comparison target hash, REXML द्वारा पढ़े गए DigestValue से आता है
    • SignedInfo Nokogiri से extract और canonicalize किया जाता है
    • SignatureValue REXML से extract किया जाता है

SAML signature verification में टूटा हुआ security link

  • SAML response, IdP से SP तक login user की जानकारी XML format में पहुंचाता है
  • HTTP POST binding का उपयोग होने पर SAML response user के browser से होकर SP तक जाता है, इसलिए user द्वारा message tamper न किया जा सके, इसके लिए signature verification आवश्यक है
  • सरल SAML response में महत्वपूर्ण जानकारी आमतौर पर Assertion के भीतर Subject और NameID में होती है
  • सामान्यतः assertion या पूरा SAML response signed हो सकता है
  • यदि assertion signed हो, तो verification दो चरणों में होती है
    • Signature हटाए गए assertion को canonicalize और hash करके DigestValue से तुलना की जाती है
    • SignedInfo को canonicalize करके SignatureValue से signature verify किया जाता है
  • इस vulnerability में दोनों चरण अलग-अलग pass हो जाने पर भी यह सुनिश्चित नहीं होता कि वे एक ही data से जुड़े हैं
    • hash वास्तविक assertion का hash हो सकता है
    • signature किसी दूसरे SignedInfo element पर किया गया signature हो सकता है
  • आवश्यक security property यह है कि hashed content, hash, और signature सीधे जुड़े हों, और verification के बाद जानकारी केवल वास्तव में verified हिस्से से ही पढ़ी जाए

वास्तविक exploit कैसे बनाया गया

  • मुख्य शर्त यह थी कि REXML और Nokogiri एक ही XML document में अलग-अलग Signature देखें, और यह वास्तव में संभव था
  • ahacker1 ने bug bounty में भाग लेते समय parser अंतर का उपयोग करने वाला working exploit पहले बनाया
    • प्रेरणा Mattermost के Juho Forsén द्वारा 2021 में प्रकाशित XML roundtrips vulnerabilities से मिली
  • GitHub Security Lab ने Trail of Bits के Ruby fuzzer ruzzy का उपयोग कर parser अंतर-आधारित एक और exploit बनाया
  • उदाहरण exploit StatusDetail element के भीतर एक अतिरिक्त Signature जोड़ता है, जो केवल Nokogiri को दिखाई देता है
  • verification flow इस तरह अलग हो जाता है
    • Nokogiri को दिखने वाले signature का SignedInfo canonicalize किया जाता है
    • REXML को दिखने वाले signature से निकाले गए SignatureValue से verify किया जाता है
    • Nokogiri द्वारा ID से खोजा गया assertion canonicalize और hash किया जाता है
    • REXML द्वारा पढ़े गए DigestValue से hash की तुलना की जाती है
  • अंततः वैध SignedInfo और वैध signature एक-दूसरे से मेल खाते हैं, और manipulated assertion तथा उससे निकला digest भी मेल खाते हैं, इसलिए ruby-saml assertion को स्वीकार कर लेता है

mitigation और detection की सीमाएँ

  • Nokogiri से SAML response parse करते समय parsing errors की जांच करने पर वर्तमान में ज्ञात कुछ private exploits को रोका जा सकता है
  • Nokogiri parsing errors exception के रूप में नहीं आतीं, इसलिए parsed document के errors member को सीधे जांचना पड़ता है
  • उदाहरण code Nokogiri::XML::ParseOptions::STRICT | Nokogiri::XML::ParseOptions::NONET options का उपयोग करता है, और doc.errors.any? होने पर error raise करता है
  • यह तरीका पूर्ण fix नहीं है, लेकिन कम से कम एक exploit को निष्पादित होने से रोक देता है
  • विश्वसनीय indicators of compromise ज्ञात नहीं हैं
    • एक संभावित indicator केवल debug-जैसे environment में ही काम करता है
    • इसे सार्वजनिक करने पर working exploit के implementation details बहुत अधिक उजागर हो जाएँगे, इसलिए इसे प्रकाशित नहीं किया गया
  • अनुशंसित जांच विधि यह है कि SP पक्ष पर user के अपेक्षित स्थान से मेल न खाने वाले IP address से हुए SAML login जैसे suspicious logins खोजे जाएँ

fix की दिशा और update targets

  • प्रारंभिक fix में API compatibility issues के कारण XML parsers में से किसी एक को हटाया नहीं गया
  • अधिक मूलभूत समस्या hash verification और signature verification के separation की थी, और parser अंतर के जरिए इसी separation का दुरुपयोग संभव हुआ
  • एक XML parser को हटाने का काम अन्य कारणों से पहले से planned था, और अतिरिक्त सुधारों के साथ यह किसी major release में किया जा सकता है
  • ruby-saml उपयोगकर्ताओं को patched 1.18.0 पर update करना चाहिए
  • ruby-saml का उपयोग करने वाली libraries की भी साथ में जांच करनी चाहिए
    • उदाहरण: omniauth-saml
    • ऐसी library को उस version पर update किया जाना चाहिए जो patched ruby-saml version को reference करता हो
  • GitHub Security Lab भविष्य में GitHub Security Lab repository पर proof-of-concept exploit प्रकाशित करने की योजना रखता है

disclosure और response timeline

  • 2024-11-04: ruby-saml के साथ SAML authentication का मूल्यांकन कर रहे GitHub test environment पर authentication bypass साबित करने वाली bug bounty report प्राप्त हुई
  • 2024-11-04: संभावित mitigation की पहचान और testing शुरू हुई
  • 2024-11-12: पहले mitigation plan को निष्प्रभावी करने वाला दूसरा authentication bypass खोजा गया
  • 2024-11-13: ruby-saml maintainer Sixto Martín से पहली बार संपर्क किया गया
  • 2024-11-14: दो parsers के अंतर को ruby-saml में report किया गया और maintainer ने तुरंत प्रतिक्रिया दी
  • 2024-11-14: maintainer और ahacker1 ने संभावित patch पर काम शुरू किया
    • शुरुआती विचारों में से एक XML parser में से एक को हटाना था, लेकिन backward compatibility तोड़े बिना यह संभव नहीं था
  • 2025-02-04: ahacker1 ने backward-incompatible fix प्रस्तावित किया
  • 2025-02-06: ahacker1 ने backward-compatible fix भी प्रस्तावित किया
  • 2025-02-12: GitHub Security Lab advisory की 90-दिन की समयसीमा समाप्त हुई
  • 2025-02-16: maintainer ने backward compatibility बनाए रखते हुए अधिक समझने योग्य fix दिशा पर काम शुरू किया
  • 2025-02-17: ruby-saml release और GitLab on-premises product release के समन्वय के लिए GitLab से पहला संपर्क किया गया
  • 2025-03-12: patched ruby-saml version release किया गया

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

1 टिप्पणियां

 
GN⁺ 2025-03-16
Hacker News की राय

  • मेरे हिसाब से GitHub का SAML implementation बेकार है
    मूल इरादा यह है कि personal account को enterprise में लाकर इस्तेमाल किया जाए, और GitHub साइट के भीतर यह कुछ हद तक काम भी करता है, लेकिन एक बार GitHub से लॉग इन किया हुआ app organization स्तर पर approve हो जाए, तो उसे organization membership पढ़ने से यह रोक नहीं पाता
    SAML session की ज़रूरत सिर्फ तब पड़ती है जब वह app उस user से मिले token के साथ data fetch करता है, और व्यवहार में SAST tools लगभग हमेशा app instance token इस्तेमाल करते थे, जबकि organization के भीतर GitHub account होना ही code दिखाने के लिए काफी था
    Tailscale ने बताने पर इसे ठीक कर दिया, Sonarcloud ने कहा कि किसी को न बताया जाए, और GitHub ने कुछ हफ्तों बाद जवाब दिया कि यह “पूरी तरह अपेक्षित व्यवहार” है, लेकिन जिन vendors को बताया गया उनमें से किसी ने भी इसे ऐसे नहीं समझा था, और documentation भी GitHub के जवाब से टकराती थी
    security bug report करना, चाहे वह संयोग से ही क्यों न मिली हो, संतोषजनक काम नहीं है; इसे पेशे के रूप में करना कैसा होगा, इसकी कल्पना करना भी मुश्किल है

    • personal account को enterprise में लाने का यह तरीका authorization से आगे की समस्याएँ भी पैदा करता है
      GitHub ने बहुत कम सही, लेकिन कभी-कभी work PR merge करते समय personal email address को default बना दिया था, इसलिए अगर कोई पूछे तो मैं GitHub हो या कहीं भी, personal और work use को एक ही account में न मिलाने की सलाह दूँगा
    • vendor पक्ष को भी कुछ हद तक समझा जा सकता है, क्योंकि GitHub यहाँ सही implementation करना बेहद मुश्किल बना देता है
      repository/commit/PR analysis tool https://dev.log.xyz बनाते समय, “जो GitHub में दिख सकता है वही Devlog में भी दिखे” यह मिलाने में बहुत मेहनत लगी, और पूरा अनुभव बेहद निराशाजनक था
      GitHub का OAuth permission selector भी ज़रूरत से ज़्यादा उलझाऊ है, इसलिए “GitHub से लॉग इन” करते समय यह निश्चित करना मुश्किल है कि किस organization की कौन-सी जानकारी share हो रही है
    • इस तरह का संचालन हर स्तर पर दोहराया जाता है
      JavaScript से परिचित युवा developers को यह समझाना भी कठिन है कि सिर्फ client-side validation काफी नहीं है, और feature requirements व budget तय करने वाले business stakeholders को समझाना तो उससे भी अधिक कठिन है
    • shared credentials से मिलने वाली सुविधा और SSO से security बेहतर हो सकती है — यह धारणा ऐसी एक vulnerability से ही ढह जाती है
      password store का कोई भी रूप, यहाँ तक कि physical storage या password reuse भी, अंततः इससे अधिक सुरक्षित साबित हो सकता है
      आखिरकार minimalism फिर जीत गया
    • जो लोग ऊपर की बात को इस vulnerability research से जोड़ना चाहेंगे, उनके लिए यह असंबंधित लगता है
      इसमें लिखा है: “GitHub doesn’t currently use ruby-saml for authentication, but began evaluating the use of the library with the intention of using an open source library for SAML authentication once more”

  • मुझे हाल ही में SAML implementation करना पड़ा था, इसलिए यह शीर्षक बिल्कुल भी चौंकाने वाला नहीं है
    SAML spec अपने आप में काफ़ी reasonable है, लेकिन उसकी नींव XML signatures, और उससे भी आगे XML canonicalization, अगर इन्हें standard कहा जा सकता है, तो सचमुच पागलपन के स्तर की चीज़ें हैं
    ऐसी टेढ़ी-मेढ़ी और भ्रष्ट spec केवल committee ही बना सकती है; मुझे नहीं लगता कि एक अकेला व्यक्ति अपने दिमाग में इतने विरोधाभासी विचारों को थामकर जोड़ पाता
    अगर signature को सिर्फ out-of-band भेज दिया जाता, तो SAML implement करने में आनंद आता

    • यह उससे भी कहीं बदतर है जितना बताया गया
      XML का मतलब ही eXtensible Markup Language है, लेकिन SAML standardization committee ने उसके ऊपर अपनी ही extension mechanism language फिर से ईजाद कर दी
      authentication cookie में जाने वाली जानकारी से बहुत अलग न होने वाले बेहद छोटे data के लिए protocol के ऊपर फिर protocol चढ़ाना, केवल सबसे बड़े और नौकरशाही से भरे committees ही कर सकते हैं — यह उसी तरह की खास बेवकूफ़ी है
    • पता नहीं SSO को मूल रूप से बचाया भी जा सकता है या नहीं
      अलग-अलग accounts में अलग से लॉग इन करने का विचार अपने आप में ठीक लगता है
      लेकिन उन accounts को जोड़कर ऐसा ढाँचा बनाना कि एक ही बार में बड़े पैमाने पर compromise हो जाएँ, बुनियादी रूप से अधिक ख़तरनाक है

  • मेरे विचार से SAML, और व्यापक रूप से XML-DSIG, व्यापक उपयोग वाले security protocols में सचमुच सबसे खराब है
    आम तौर पर किसी भी कीमत पर OAuth पर migrate कर जाना चाहिए, और कम से कम मैं तो नया product बाजार में लाते समय इस पर निर्भर रहने से इनकार करूँगा
    यह बेहद ख़तरनाक है, और जब तक practical formal verification में कोई breakthrough नहीं आता, यह कल्पना करना कठिन है कि यह आख़िरी DSIG vulnerability होगी या सबसे बुरी vulnerability होगी

    • कभी न कभी मैं XML DSig की वे सारी अविश्वसनीय रूप से मूर्खतापूर्ण चीज़ें लिखूँगा जो यह करता है
      cryptography को छुए बिना भी यह enterprise software वाली सोच की पराकाष्ठा है
      किसी को WS-* और OASIS/XACML जैसी चीज़ों की mailing lists और standardization bodies की तबाही में गहराई तक उतरना चाहिए
    • यह देखना दिलचस्प होगा कि Security Cryptography Whatever इस हफ्ते के SAML chaos को कैसे cover करता है
    • अगर मैंने सही समझा है, तो SAML की एक अलग पहचान अभी भी यह है कि SSO provider session को revoke कर सकता है
      क्या यह सही है?

  • उफ़, अगर कोई दूसरा विकल्प हो तो किसी को भी REXML इस्तेमाल नहीं करना चाहिए
    यह गलत XML को भी खुशी-खुशी parse कर देता है, और बाद के चरणों में अनगिनत समस्याएँ पैदा करता है
    यह सचमुच regular expressions से XML parse कर रहा है, और यह क्यों नहीं करना चाहिए इसका शानदार उदाहरण है
    projects ने performance के कारण Nokogiri इस्तेमाल करना शुरू नहीं किया था, बल्कि correctness के कारण किया था

    • क्या यह textbook example नहीं है?
      जो regular language नहीं है, उसे regular expressions से parse मत करो
    • AI code assistants के खतरों में से एक यह है कि वे बड़े codebase में इस्तेमाल हो रही libraries के व्यापक संदर्भ को ज़रूरी नहीं देखते
      मैंने हाल ही में o3 को test किया, और हर बार जब वह किसी खास code block की library से असंबंधित समस्या ठीक करने की कोशिश करता, तो उसी block में इस्तेमाल library बदल देता
      Sonnet में मैंने ऐसा व्यवहार नहीं देखा
      इससे ऐसा लगता है कि fix की प्रक्रिया में codebase या standard library में पहले से मौजूद होने के कारण tests pass कर जाने वाली, और Gemfile बदलने की ज़रूरत भी न पड़ने वाली, लेकिन अधिक घटिया library/gem आसानी से अंदर घुस सकती है

  • SAML डिज़ाइन के हिसाब से सुरक्षित नहीं है
    इस बारे में पहले से बेहतर समझाने वाले लेख मौजूद हैं, उदाहरण के लिए https://joonas.fi/2021/08/saml-is-insecure-by-design/
    यहाँ एक पुराने थ्रेड की याद रह जाने वाली पंक्ति थी: “अर्थ पर नहीं, bytes पर sign करो”
    parsers के बीच का अंतर अनुमानित होता है और कभी-कभी अपरिहार्य भी
    signed response से आप क्या हासिल करना चाहते हैं, यह बहुत महत्वपूर्ण है
    modern TLS की दुविधाओं में से एक यह है कि कभी-कभी आप सिर्फ एक internal CA पर भरोसा करना चाहते हैं, और वह आसान रास्ता है, लेकिन अगर partner का CA certificate स्वीकार करना पड़े और partner कई हों, तो फिर सिर्फ end certificate देखना काफी नहीं रहता और chain का root भी decision-making में उतना ही महत्वपूर्ण हो जाता है
    इसलिए जहाँ संभव हो AWS signing algorithm से भी बचने की सलाह दी जाती है
    V4 सैद्धांतिक रूप से सुरक्षित है, लेकिन AWS इसे दो बार बिगाड़ चुका है, और SigV1 तथा SigV3 डिज़ाइन के हिसाब से सुरक्षित नहीं थे, फिर भी किसी तरह design review पार करके public में जारी हो गए

  • शानदार लेख है
    जैसा कि लेख में भी कहा गया है, ahacker1 के लिए ज़ोरदार तालियाँ बनती हैं
    SAML implementation को सुरक्षित बनाने के लिए वे बेहद परिष्कृत और मूल्यवान काम कर रहे हैं, और SSOReady भी उनके काम के लिए सच में आभारी है
    इस हफ़्ते की शुरुआत में WorkOS ने भी ahacker1 के साथ सहयोग पर एक अच्छा लेख प्रकाशित किया था: https://workos.com/blog/samlstorm

  • इसमें “GitLab में इस vulnerability का exploitable case मिला और security team को बताया गया” वाला हिस्सा है, तो जिज्ञासु लोगों के लिए बता दें कि GitLab ने patch पहले ही जारी कर दिया है
    https://about.gitlab.com/releases/2025/03/12/patch-release-g...

  • संबंधित लेख के रूप में Latacora का 2019 का लेख, How (not) to sign a JSON object[1], भी है
    सार यह है कि tree structure को nest करके sign करना कठिन है और उसमें कई pitfalls हैं
    envelope अगर message को raw string के रूप में रखे और उसी raw string पर sign किया जाए, तो वह ज़्यादा आसान है
    [1]: https://www.latacora.com/blog/2019/07/24/how-not-to/

  • यहाँ इससे भी सरल निष्कर्ष यह नहीं है कि जहाँ signature होना चाहिए, वहीं signature खोजो?
    “//ds:Signature” जैसे ज़रूरत से ज़्यादा सामान्य XPath का उपयोग करके किसी भी अनपेक्षित जगह का कोई भी signature मत खोजो

    • लगता है कि vulnerability के जवाब अक्सर बहुत ढीले होते हैं
      सिर्फ खतरनाक component को सर्जिकल तरीके से हटाना नहीं, बल्कि कभी-कभी थोड़ा बहुत ज़्यादा काटना भी पड़ता है, जैसे बड़े पैमाने पर छाँटकर anti-cancer therapy की तरह निपटना
      किसी स्वाभिमानी IT administrator को अपनी आगे की योजना से SAML को बाहर कर देना चाहिए
      SSO का पूरा विचार भी संदिग्ध है, और XML parsing से हफ़्ते में दो बार चोट खा चुके हैं, इसलिए आगे इससे बचना चाहिए
      XML को JSON से बदलने वाली policy में दिक्कत ही क्या है?
    • थोड़ा उग्र ढंग से कहें तो, निष्कर्ष यह है कि बड़ा डंडा लेकर web developers को security-sensitive code के पास हाथ लगाने से रोकना चाहिए
      डिज़ाइन, protocol, data format — सबमें ऐसा होना चाहिए
      सामान्य web development की आदतें और design considerations, security code की ज़रूरतों से मेल नहीं खातीं, और अक्सर सही कोड लिखने की ज़रूरतों के भी ठीक उलट होती हैं

  • blog post में vulnerability समझाते हुए असली समस्या बने parser difference को ही छोड़ देना थोड़ा खीज पैदा करता है
    यह ऐसा है जैसे कहानी की भूमिका लिखकर उसका चरम भाग हटा दिया जाए

    • sibling comment वाले blog post <https://news.ycombinator.com/item?id=43374972> में संबंधित विवरण थे
      (...//ds:DigestValue).firstChild.nodeValue किया गया, लेकिन .firstChild के Node होने की जाँच नहीं की गई, और समस्या वाले case में वह Comment था
      इसलिए unpatched पक्ष ने “छिपा हुआ” signature देखा, जबकि comments हटाने वाले patched पक्ष ने Node देखा, और जब दोनों implementations signed document के बारे में अलग-अलग निर्णय लें, तो नतीजा सुखद नहीं होता
    • शायद वे दुनिया भर की असंख्य systems में authorization bypass संभव बनाने वाले zero-day को, उन systems के जिम्मेदार लोगों को उसे ठीक करने का मौका मिलने से पहले, सीधे public करने की जिम्मेदारी नहीं लेना चाहते थे
      ठोस विवरण शायद जल्द ही सामने आएँगे