- 2008 में GitHub के SSH लॉगिन bottleneck को ठीक करने का काम, अलग-अलग उपयोगकर्ताओं के पास एक ही SSH key fingerprint होने वाली असामान्य टक्कर सामने आने का कारण बना
- GitHub ने बढ़ती
authorized_keysफ़ाइल की linear search समस्या से बचने के लिए OpenSSH को patch करके key fingerprint को MySQL में lookup करने का तरीका अपनाया - patch तैनात होने के बाद SSH के जरिए दूसरे उपयोगकर्ता के repository तक पहुंच होने की समस्या आई, लेकिन बार-बार दिख रहे key fingerprint collision को सिर्फ patch bug मानना मुश्किल था
- 13 मई 2008 को DSA-1571-1 के सार्वजनिक होने से पुष्टि हुई कि Debian OpenSSL लगभग 18 महीनों तक predictable private keys बना रहा था, और संभावित keys की संख्या प्रति उपयोगकर्ता घटकर 32,000 से थोड़ा अधिक रह गई थी
- बड़े security incident अक्सर “कुछ अजीब है” जैसे छोटे संकेतों से शुरू होते हैं, और उस सुराग को अंत तक पीछा करने का समय और क्षमता ही असली फर्क पैदा करते हैं
GitHub SSH लॉगिन bottleneck से शुरू हुई घटना
- मार्च 2008 में, Engine Yard में काम कर रहे लेखक को Rails-केंद्रित hosting कंपनी के ग्राहक GitHub की SSH लॉगिन performance समस्या में मदद करने के लिए कहा गया
- GitHub
git@github.comपर SSH कनेक्शन के बाद public key authentication के जरिए Git repository access देता था - उस समय key management सामान्य तरीके से
~/.ssh/authorized_keysफ़ाइल पर निर्भर था- SSH जब public key authentication अनुरोध पाता है, तो
authorized_keysफ़ाइल खोलकर जमा की गई key से मेल खाने वाली entry को linear search से ढूंढता है - सामान्य account में keys बहुत कम होती हैं, इसलिए समस्या बड़ी नहीं होती, लेकिन तेज़ी से बढ़ रहे GitHub में एक ही बड़ी फ़ाइल में सभी SSH keys जमा होने लगीं और लॉगिन समय साफ़ तौर पर धीमा हो गया
- SSH जब public key authentication अनुरोध पाता है, तो
OpenSSH patch और MySQL key lookup
- कई विकल्पों की समीक्षा के बाद, GitHub टीम और लेखक ने OpenSSH को patch करके key fingerprint के आधार पर MySQL database से key lookup करने का तरीका चुना
- यह फैसला हल्के में लेने लायक बदलाव नहीं था
- OpenSSH में बदलाव गलत होने पर security के लिहाज़ से गंभीर हो सकता था
- बाकी विकल्प इससे भी खराब थे, इसलिए इसे “सबसे कम बुरा” तरीका माना गया
- बदलाव के काम का बड़ा हिस्सा इस बात की पुष्टि करने में लगा कि security से समझौता न हो
- अप्रैल 2008 की शुरुआत में तैनाती के बाद SSH लॉगिन तेज़ हो गया, और कुछ समय तक लगा कि अब इस समस्या की चिंता नहीं करनी पड़ेगी
duplicate key fingerprint जैसा असंभव लगने वाला लक्षण
- मई 2008 की शुरुआत में GitHub टीम से संदेश आया कि कुछ GitHub उपयोगकर्ता SSH के जरिए दूसरे उपयोगकर्ताओं के repository तक पहुंच पा रहे हैं
- समस्या सीधे SSH key authentication से जुड़ी थी, और ठीक उससे पहले OpenSSH patch तैनात किया गया था, इसलिए लेखक द्वारा लिखे गए code पर पहले शक गया
- debugging के बाद पुष्टि हुई कि दो अलग उपयोगकर्ताओं के पास एक ही key fingerprint है
- अगर उपयोगकर्ताओं ने आपस में key साझा न की हो, तो यह लगभग असंभव सी बात थी
- प्रभावित उपयोगकर्ता एक-दूसरे को नहीं जानते थे और उन्होंने कहा कि उन्होंने अपनी key कभी सार्वजनिक नहीं की
- बाद में एक और उपयोगकर्ता-जोड़ी में भी वही स्थिति मिली, और उनका fingerprint पहले मामले से अलग था
- इससे यह मानना मुश्किल हो गया कि यह सिर्फ एक संयोग या web application bug है
- पर्याप्त पुष्टि हो जाने के बाद कि OpenSSH patch कारण नहीं था, लेखक की सीधी भागीदारी कम हो गई
- लेखक GitHub कर्मचारी नहीं थे, और Engine Yard के दूसरे ग्राहकों के support काम भी संभालने थे
- GitHub टीम ने उपयोगकर्ताओं से पुष्टि जारी रखी और पाया कि साझा बिंदु यह था कि SSH keys Debian या Ubuntu सिस्टम पर बनाई गई थीं
Debian OpenSSL भेद्यता के सार्वजनिक होने से सामने आया कारण
- 13 मई 2008 को DSA-1571-1 सार्वजनिक होने पर स्थिति साफ़ हो गई
- Debian OpenSSL package लगभग 18 महीनों तक predictable private keys बना रहा था
- कारण यह था that OpenSSL random number generation code को साफ़ करते समय Debian maintainer ने अनजाने में संभावित key space को बहुत छोटा कर दिया
- किसी खास उपयोगकर्ता द्वारा बनाई जा सकने वाली keys की संख्या “बेहद विशाल” से घटकर 32,000 से थोड़ा अधिक रह गई
- GitHub पर बहुत से उपयोगकर्ता जुड़ रहे थे, और उनमें से कुछ ने संभवतः recommended practice के अनुसार अलग से नई key बनाई होगी, जिसके परिणामस्वरूप collision हो सकता था
- इस खुलासे ने निर्णायक प्रमाण दे दिया कि लेखक का OpenSSH patch इसका कारण नहीं था
बाद में Debian weak keys से जुड़ा काम
- आगे चलकर लेखक का Debian weak keys से और भी अधिक संपर्क हुआ
- pwnedkeys.com चलाते हुए उन्होंने ज्ञात compromised keys का बड़ा repository संभाला
- इन keys का उपयोग करके गलत तरह से काम कर रही Certificate Authority को खोजने का काम भी किया
“कुछ अजीब है” का पीछा करने के लिए समय ने जो फर्क बनाया
- CVE-2008-0166 बनी इस भेद्यता को Luciano Bello ने ठीक कब और कैसे खोजा, यह लेखक पता नहीं लगा सके
- कमजोर code वाला stable Debian release सार्वजनिक खुलासे से एक साल पहले आ चुका था, इसलिए key collision देखकर “कुछ अजीब है” महसूस करने के बाद गहराई से जांच करने का समय रहा हो सकता था
- हाल का XZ backdoor भी “कुछ अजीब है” जैसी observation और गहन जांच के बाद सामने आए मामले से जुड़ता है
- अहम बात यह है कि ऐसी गहन जांच वास्तव में करने की क्षमता और समय हो
- लेखक उस समय खुद इतनी गहराई से जांच नहीं कर पाए
- GitHub टीम भी तेज़ी से बढ़ती service में feature development और incident response में व्यस्त थी
- लेखक भी Engine Yard में support tickets संभाल रहे थे
- सही समय पर सही skills, समय और ऊर्जा वाला कोई व्यक्ति जब उस सुराग को अंत तक ले जा पाता है, तभी बड़ा फर्क बनता है
1 टिप्पणियां
Hacker News की राय
“Luciano Bello ने बाद में CVE-2008-0166 कहलाने वाली कमजोरी को ठीक कब और कैसे खोजा, यह पता नहीं चल पाया” वाली बात पर, उस समय के IRC logs में यह दर्ज है
17:23 < luciano> has really an accident. I was needing many primes numbers... 0:-)17:23 < Sesse> and you got the same numbers every time?17:25 < luciano> Sesse, not every time :P“सही skill, time और energy वाला कोई व्यक्ति ठीक उसी समय मौजूद था, यह इंडस्ट्री की किस्मत थी” — यह बहुत-सी निगाहों और “sunlight is the best disinfectant” वाली बात को सच होते दिखाता है
किसी का यूँ ही गुजरते हुए bug पकड़ लेना कितना भी दुर्लभ लगे, यह संभव है, इसलिए वास्तव में होता भी है
proprietary/closed source code में यह संभावना लगभग 0 के करीब होती है
किसी ने कुछ असामान्य नोटिस किया, और source code के साथ वास्तविक स्थिति की जाँच करके देखा जा सका कि कुछ संदिग्ध हुआ था
बड़े distributions के security experts से संपर्क किया गया ताकि वे आगे review कर सकें, और उन्होंने भी security issue की पुष्टि कर तुरंत प्रतिक्रिया दी
सार्वजनिक होने के बाद software और security के अलग-अलग क्षेत्रों की विशेषज्ञता रखने वाले लोग यह खंगाल सके कि क्या और कैसे किया गया था, और खतरा क्या था
उसी developer द्वारा दूसरे software में छोड़े गए संदिग्ध commits भी trace और verify किए गए, और उनके प्रभाव का analysis अब भी जारी है
हर distribution build archive के आसपास compromise कैसे हुआ, इस तरह की details को लेकर अधिक संवेदनशील हो गया, और आगे ऐसे मामलों को पकड़ने और रोकने के तरीके ढूँढने शुरू किए
closed source की तुलना में, वास्तविक exploitation होने से पहले “software थोड़ा slow है” जैसी reports पर शायद ही ध्यान दिया जाता
और अगर कंपनी आखिरकार पता भी लगा लेती, तो भी संभवतः बहुत सावधानी से, न्यूनतम जानकारी के साथ ही समझाती, जिससे पूरी इंडस्ट्री की दोहराव रोकने की क्षमता काफ़ी घट जाती
लेकिन अक्सर उन्हें ठीक नहीं किया जाता, या कोई कार्रवाई ही नहीं होती
ज़्यादातर लोगों को bug मिलने पर यह भी नहीं पता होता कि क्या करना चाहिए। बहुत पहले मैं भी ऐसा ही था, और बाद में जाकर समझ आया कि जो चीज़ें मैंने देखी थीं वे bugs थीं
लगभग 30 साल पहले की बात है, इसलिए details धुंधली हैं, लेकिन याद है कि Windows पर Microsoft NetMeeting के साथ छेड़छाड़ करते हुए मैं buffer overrun error से crash करा सकता था
तब मैं computer का beginner था, और यह नहीं समझता था कि network application में buffer overflow बहुत बुरी चीज़ होती है। लगता है इंडस्ट्री में लंबे समय से रहे बहुत-से लोग भी तब यह नहीं समझते थे
उस दौर में security issues report करना भी कहीं ज़्यादा कठिन था, और कुछ मामलों में जोखिम भरा भी
आखिरकार कई चीज़ों की ज़रूरत होती है। समस्या से टकराना, यह पहचानने लायक गहरी computing समझ होना कि वह समस्या गंभीर है, bug report करने का ऐसा माध्यम होना जहाँ लोग उसे देखें, और रिपोर्ट को कब व कैसे संभालना है यह जानने वाली security culture — ये सब ज़रूरी हैं
लेकिन वही पंक्ति पढ़ते हुए मेरे मन में सवाल यह आया कि Heartbleed, CVE-2008-0166, xz जैसी गंभीर security bugs कितनी बार होती रही होंगी, बिना खोजे और बिना सार्वजनिक हुए
इस कमजोरी के बारे में हाल ही में पता चली एक अहम बात यह है कि यह बदलाव किसी जल्दबाज़ी में किया गया काम नहीं था
maintainer ने OpenSSL mailing list पर अपनी देखी हुई समस्या पोस्ट की थी, feedback माँगा था, और fix का प्रस्ताव भी रखा था; इसमें upstream सहित कुछ जवाब भी मिले थे
नतीजा भयानक कमजोरी निकला, लेकिन यह ज़्यादा बेहद खराब किस्मत जैसा लगता है, जहाँ सभी से समस्या छूट गई
इसके अलावा upstream OpenSSL code undefined behavior को invoke कर रहा था। इसलिए compiler अगर Debian maintainer के किए गए ठीक उसी transformation को कर देता, तो वह भी वैध हो सकता था
उस समय यह बात अकादमिक लगती थी। लगता था, भला compiler इतना बुरा कैसे हो सकता है
बाद में यह समझ बेहतर हुई कि undefined behavior से पूरी तरह बचना चाहिए
और फिर 8 साल बाद Heartbleed मिलने पर सबको अचानक एहसास हुआ कि OpenSSL का maintenance कितना खराब रहा था
बचाव में इतना कहा जा सकता है कि यह काम लगभग volunteer effort जैसा था, और अच्छी बात यह रही कि बाद में funding मिलने से स्थिति सुधरी
security के लिए महत्वपूर्ण random number generator code में, बहुत बड़ी मात्रा में random numbers generate करके यह जाँचना कि वे सभी unique हैं, ऐसा test सचमुच ज़रूरी लगता है
इसे पढ़कर यह जिज्ञासा होती है कि लोकप्रिय Bitcoin hardware wallets में से किसी एक के seed generation function में भी ऐसा पहले कभी हुआ होगा या आगे होने की संभावना कितनी है
और उसका असर क्या होगा, यह भी जानने की उत्सुकता होती है
पिछले 22 महीनों में Unciphered, browser-based cryptocurrency wallet generation में व्यापक रूप से इस्तेमाल होने वाले BitcoinJS और इस software से बने products और projects को प्रभावित करने वाली एक vulnerability पर काम करता रहा है
वर्षों के दौरान इस vulnerability ने काफ़ी बड़ी संख्या में कमजोर cryptocurrency wallets बनवाए
SSH vulnerability के मामले में आपको सक्रिय रूप से यह जाँचना पड़ता है कि जिस server तक पहुँचना है उसके पास उन खराब fingerprints में से कोई है या नहीं, लेकिन wallet वाले मामले में नेटवर्क पर अपने-आप दूसरों के funds तक पहुँचना संभव हो जाता है
हालांकि उस मामले में इसके जानबूझकर डाले जाने की संभावना कम है
मौजूदा तकनीक के साथ इसमें शायद लाखों साल की computation लगे, लेकिन किसी state actor के लिए, जो लगभग असीमित पैसा लगाकर कुछ हफ़्तों में इतनी computation चला सके, यह पूरी तरह असंभव दायरे से बाहर न हो
आख़िरकार ऐसा समय आ सकता है जब address जानने वाला कोई भी व्यक्ति सभी wallets तक पहुँच सके
अगर आप दिमाग और पैसे वाले किसी व्यक्ति के निशाने पर आ सकते हैं, तो Bitcoin value store करने के लिए इतना सुरक्षित नहीं है
“Ezra Zygmuntowitz ने मुझे GitHub से मिलवाया और GitHub team के साथ समस्या को गहराई से खंगालने का समय दिया” यह वाक्य मज़ेदार है
शायद मैं native speaker नहीं हूँ, इसलिए इसे ऐसे भी पढ़ा जा सकता है कि ख़ुद GitHub team में कोई बड़ी समस्या है, और मुझे लगा अगली पंक्तियाँ उसी को खंगालेंगी
“अगर Luciano ने इसे नहीं खोजा होता, तो पता नहीं यह कितने समय बाद मिलता” वाला हिस्सा देखते हुए, शायद GitHub या किसी बड़े cloud provider जैसा कोई ही इसे संयोग से टकराकर खोज पाता
क्योंकि ऐसे बहुत ज़्यादा स्थान नहीं हैं जहाँ हज़ारों-लाखों user keys संग्रहीत हों
यानी वाक्य को
(समस्या को खंगालना) (GitHub team के साथ)की तरह पढ़ना चाहिए, या(GitHub team से संबंधित समस्या) को खंगालनाकी तरह, यही सवाल हैइसे सही तरह से संभालना काफ़ी मुश्किल माना जाता है
मेरी समझ के मुताबिक OpenSSL random number generator को uninitialized stack memory और PID से seed किया जाता था, और Debian ने इसे सिर्फ़ PID से seed होने लायक बना दिया
लेकिन क्या Debian patch के बिना भी यह पहले से काफ़ी ख़तरनाक नहीं था?
OpenSSL code में byte chunks को copy करने के दो स्थान थे, और उनमें से एक uninitialized garbage value copy कर सकता था। यह निश्चित रूप से ग़लत था
किसी ने इसे ठीक करने वाला patch लिखा, और फिर LLM की मदद के बिना, शुद्ध मानवीय अक्षमता से, किसी ने कहा, “पास में एक और मिलती-जुलती copy है, इसे भी हटाना चाहिए”
Debian ने दोनों बदलावों वाला patch शामिल कर दिया
नतीजतन OpenSSL अब कोई bytes copy ही नहीं कर रहा था
uninitialized data copy न करना अच्छी बात थी, लेकिन असली random entropy भी pool में copy नहीं हो रही थी. यह
“कई संभावित समाधानों की समीक्षा करने के बाद, हमने निष्कर्ष निकाला कि सबसे कम बुरा विकल्प OpenSSH को patch करना था ताकि वह key fingerprint को index की तरह इस्तेमाल करने वाले MySQL database में keys ढूँढ सके” वाले हिस्से में यह सवाल उठता है कि sqlite की जगह MySQL क्यों?
मामला
~/.ssh/authorized_keysतक पहुँच को तेज़ करने का था, और ऐसा use case तो मानो MySQL के चमकने के लिए ही बना होOpenSSH को
~/.ssh/authorized_keys.dbजाँचने लायक patch करना, उसे MySQL इस्तेमाल कराने के लिए patch करने से कम काम लगतायह भी काफ़ी संभव है कि MySQL पहले से production में चल रहा हो। तब वहाँ data store करने की शुरुआती लागत भी नहीं होती
वैसे भी user database कहीं न कहीं पहले से मौजूद रहा होगा
कमजोर keys के छोटे समूह की खोज से अलग, धीमा SSH login time कई कारणों से खींचकर देखने लायक एक दिलचस्प सुराग है
एक और दिलचस्प प्रसंग वह है जहाँ greatest common divisor का उपयोग करके समान
pयाqfactor वाले RSA keys का पता लगाया गया: https://factorable.net/weakkeys12.extended.pdfयह जानने की जिज्ञासा है कि क्या GitHub अब भी patched openssh चला रहा है
GitHub Enterprise की एक copy खरीदें, files की obfuscation हटाएँ और देख लें। deobfuscation एक दिलचस्प चुनौती है और बहुत मुश्किल भी नहीं
अफ़सोस कि यह open source नहीं है, इसलिए code को साझा करना, उस पर बात करना, या GitHub पर link देना संभव नहीं
फिर भी अगर GitHub Enterprise अब भी ऐसा patch इस्तेमाल कर रहा है, तो संभावना है कि असली production GitHub भी वही कर रहा हो
~/.ssh/authorized_keysमें डालने वाले तरीके पर नहीं गया होगाgithub.comके port 22 पर telnet करके देखें, version string तुरंत दिख जाती हैसुधार: पहले मैंने golang कहा था, लेकिन जाँचने पर पता चला कि golang इस्तेमाल करने वाला Bitbucket था