Debian की weak keys vulnerability से टकराने की कहानी

 (hezmatt.org)
2 पॉइंट द्वारा GN⁺ 2024-04-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Debian की weak keys vulnerability का शिकार होने की कहानी

  • मार्च 2008 में, लेखक Engine Yard(EY) में काम कर रहे थे
  • उस समय EY, GitHub को मुफ्त में infrastructure उपलब्ध कराकर मदद कर रहा था
  • GitHub के बढ़ने के साथ SSH login time धीमा होने की समस्या आने लगी
  • GitHub, SSH keys को मैनेज करने के लिए standard तरीका ~/.ssh/authorized_keys file इस्तेमाल कर रहा था
  • SSH, जब कोई user connect करता है, तो इस file को खोलकर user द्वारा प्रस्तुत key से मेल खाने वाली key को linear search से ढूंढता है
  • आम तौर पर keys कम होती हैं, इसलिए समस्या नहीं होती, लेकिन GitHub की तरह users बहुत बढ़ जाएं तो यह धीमा हो जाता है

authorized_keys file की जगह MySQL DB इस्तेमाल करने का फैसला

  • कई विकल्पों की समीक्षा करने के बाद, OpenSSH को patch करके key lookup को MySQL DB में करने के लिए बदलने का निर्णय लिया गया
  • यह एक सावधानीपूर्वक लिया गया फैसला था, और security को नुकसान न पहुंचे इसके लिए काफी मेहनत की गई
  • अप्रैल 2008 की शुरुआत में इसे लागू किया गया और SSH login speed की समस्या हल हो गई

अजीब घटना

  • एक महीने बाद, मई की शुरुआत में, कुछ users SSH के जरिए दूसरे users के repositories तक पहुंच पाने लगे
  • जांच में पता चला कि अलग-अलग users ऐसी keys इस्तेमाल कर रहे थे जिनका key fingerprint एक ही था
  • ऐसा तब तक नहीं हो सकता जब तक key साझा न की गई हो
  • users का कहना था कि वे एक-दूसरे को नहीं जानते और उन्हें नहीं पता कि key कैसे लीक हुई
  • दूसरे user pairs में भी वही समस्या मिली
  • एकमात्र समानता यह थी कि वे सभी Debian या Ubuntu systems इस्तेमाल कर रहे थे

कारण का पता चला

  • 13 मई 2008 को DSA-1571-1 जारी होने के साथ सब कुछ स्पष्ट हो गया
  • Debian maintainer ने OpenSSL के random number generation code को साफ करते समय गलती से संभावित keys की संख्या घटाकर लगभग 32,000 कर दी
  • बहुत से लोग GitHub पर साइन अप करते समय best practice के अनुसार नई keys बना रहे थे, और इसी वजह से collisions हुए
  • बाद में लेखक इस समस्या से और अधिक जुड़ गए, जैसे ज्ञात कमजोर keys का उपयोग करके समस्याग्रस्त certificate authorities की पहचान करना

GN⁺ की राय

  • इतनी महत्वपूर्ण vulnerability खोजने के लिए यह महसूस करना ज़रूरी है कि "कुछ अजीब है", और फिर लगातार जांच करने का समय और ऊर्जा होना भी ज़रूरी है। आम तौर पर ऐसा अवसर नहीं मिलता, इसलिए कई बार किस्मत भी साथ देनी पड़ती है।
  • ज़्यादातर लोग रोज़मर्रा की व्यस्तता में इतने उलझे रहते हैं कि समस्या के मूल कारण तक पहुंचना मुश्किल हो जाता है। हमारे उद्योग के लिए यह महत्वपूर्ण चुनौती है कि हम ऐसी गुंजाइश फिर से हासिल करें।
  • OpenSSL सबसे व्यापक रूप से इस्तेमाल होने वाली cryptography libraries में से एक है, इसलिए ऐसी vulnerability का असर बहुत बड़ा होता है। open source की ताकत और कमजोरी दोनों यहां साफ दिखती हैं।
  • ऐसी vulnerabilities को रोकने के लिए code review और security audit को मजबूत करना चाहिए, और महत्वपूर्ण हिस्सों में बदलावों की और अधिक सावधानी से समीक्षा करनी चाहिए। लेकिन कोई भी तरीका पूरी तरह परफेक्ट नहीं है।
  • इसके बावजूद, open source का फायदा यह है कि experts खुद code देखकर समस्याएं खोज सकते हैं। बंद programs में यह भी संभव नहीं होता।

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

1 टिप्पणियां

 
GN⁺ 2024-04-10
Hacker News राय
  • Luciano Bello ने संयोग से CVE-2008-0166 vulnerability खोजी, लेकिन उस समय के IRC logs के अनुसार कई primes की ज़रूरत थी और हर बार वही संख्या नहीं मिलती थी
  • लगता है कि पूरी industry काफ़ी हद तक lucky रही, क्योंकि किसी ऐसे व्यक्ति के पास सही समय पर फ़र्क पैदा करने वाली skill, time और energy थी. यह "many eyes" और "sunlight is the best disinfectant" वाली बात को सांख्यिकीय रूप से महसूस कराने वाला हिस्सा है. किसी के संयोग से bug खोज लेने की संभावना चाहे कितनी भी कम हो, लोग ऐसा कर सकते हैं, इसलिए वह खोजा जाता है. वहीं proprietary/closed-source code में वह संभावना 0 होती है
  • इस vulnerability का कारण बना बदलाव जल्दबाज़ी में नहीं किया गया था. एक maintainer ने OpenSSL mailing list पर मुद्दा उठाया, feedback माँगा और समाधान प्रस्तावित किया, और upstream सहित कुछ feedback भी मिला. नतीजा एक भयानक vulnerability था, लेकिन यह एक बेहद दुर्भाग्यपूर्ण मामला लगता है जहाँ कोई भी समस्या पकड़ नहीं पाया
  • GitHub ने निष्कर्ष निकाला कि MySQL database में key fingerprint से indexed keys को lookup करने के लिए OpenSSH को patch करना सबसे अच्छा विकल्प था. ~/.ssh/authorized_keys तक access की speed बढ़ाने की कोशिश वाले हालात में MySQL चमक सकता था, इसलिए लगता है कि इसे SQLite के बजाय चुना गया
  • यह सोचने पर मजबूर करता है कि किसी लोकप्रिय Bitcoin hardware wallet के seed generation function में ऐसा होने की संभावना और उसके प्रभाव क्या हो सकते हैं
  • GCD का इस्तेमाल करके common 'p' या 'q' factors वाले RSA keys को detect करना भी एक दिलचस्प प्रसंग था
  • देखा जा सकता है कि धीमा SSH login time कई कारणों से खींचने लायक एक महत्वपूर्ण सुराग है
  • OpenSSL RNG को uninitialized stack memory और PID से seed किया गया था, और Debian patch के बिना भी केवल PID से seed करना अपने-आप में काफ़ी जोखिमभरा लगता है
  • यह जानने की जिज्ञासा है कि क्या GitHub अब भी patched OpenSSH चला रहा है
  • यह पंक्ति मज़ेदार है कि Ezra Zygmuntowicz ने लेखक को GitHub से मिलवाया और GitHub team के साथ समस्या में गहराई से जाने का समय दिया. शायद इसलिए क्योंकि इसे पढ़कर ऐसा लग सकता है मानो GitHub team में ही कोई बड़ी समस्या थी
  • अगर Luciano ने इसे नहीं खोजा होता, तो पता नहीं यह और कितने समय तक अनदेखा रहता. लगता है कि GitHub या बड़े cloud providers जैसे, जो users से हज़ारों keys store करते हैं, ऐसे बहुत कम स्थान थे जो इसे संयोग से खोज सकते थे