इस भेद्यता का एक उच्च संभावित प्रभाव है क्योंकि यदि आपके सिस्टम पर हमला किया गया है, तो यह पैचिंग के बाद भी असुरक्षित रहेगा, और हमलों ने लॉग में कोई निशान नहीं छोड़ा होगा। संभावना है कि यदि आप जल्दी से समझौता कर लेते हैं और आप एक हाई-प्रोफाइल लक्ष्य नहीं हैं, तो किसी ने भी आप पर हमला करने के लिए आस-पास नहीं पहुंचाया होगा, लेकिन यह सुनिश्चित करना मुश्किल है।
क्या मैं असुरक्षित हूं?
ओपनएसएसएल का छोटी गाड़ी संस्करण
छोटी गाड़ी का सॉफ्टवेयर OpenSSL लाइब्रेरी है। 1.0.1 अप टू 1.0.1f , और ओपनएसएसएल 1.0.2 बीटा 1 तक। पुराने संस्करण (0.9.x, 1.0.0) और वे संस्करण जहां बग को ठीक किया गया है (1.0.1g बाद में, 1.0.2 बीटा 2 आगे) प्रभावित नहीं होते हैं। यह एक कार्यान्वयन बग है, प्रोटोकॉल में कोई दोष नहीं है, इसलिए केवल ओपनएसएसएल पुस्तकालय का उपयोग करने वाले कार्यक्रम प्रभावित होते हैं।
आप openssl version -aओपनएसएसएल संस्करण संख्या प्रदर्शित करने के लिए कमांड लाइन टूल का उपयोग कर सकते हैं । ध्यान दें कि कुछ वितरण पहले के रिलीज़ के लिए बग फिक्स को पोर्ट करते हैं; यदि आपके पैकेज के परिवर्तन लॉग में हार्टलेड बग फिक्स का उल्लेख है, तो यह ठीक है, भले ही आपको 1.0.1f जैसा संस्करण दिखाई दे। यदि openssl version -aनिर्माण तिथि (नहीं पहली पंक्ति पर तारीख) 2014-04-07 की शाम यूटीसी या बाद में चारों ओर का उल्लेख है, आप ठीक होना चाहिए। ध्यान दें कि ओपनएसएसएल पैकेज 1.0.0इसके नाम में भले ही संस्करण 1.0.1 ( 1.0.0बाइनरी संगतता को संदर्भित करता है) हो सकता है।
प्रभावित आवेदन
शोषण एक आवेदन के माध्यम से किया जाता है जो एसएसएल कनेक्शन को लागू करने के लिए ओपनएसएसएल लाइब्रेरी का उपयोग करता है । कई एप्लिकेशन अन्य क्रिप्टोग्राफ़िक सेवाओं के लिए ओपनएसएसएल का उपयोग करते हैं, और यह ठीक है: बग एसएसएल प्रोटोकॉल की एक विशेष सुविधा के कार्यान्वयन में है, "दिल की धड़कन"।
आप जाँच सकते हैं कि आपके सिस्टम पर लाइब्रेरी के खिलाफ कौन से प्रोग्राम जुड़े हुए हैं। उन सिस्टमों पर जो dpkg और apt (Debian, Ubuntu, Mint,…) का उपयोग करते हैं, निम्न कमांड उन पुस्तकालयों के अलावा अन्य स्थापित संकुल को सूचीबद्ध करता है जो उपयोग libssl1.0.0(प्रभावित पैकेज):
apt-cache rdepends libssl1.0.0 | tail -n +3 |
xargs dpkg -l 2>/dev/null | grep '^ii' | grep -v '^ii lib'
यदि आप इस सूची में कुछ सर्वर सॉफ़्टवेयर चलाते हैं और एसएसएल कनेक्शनों को सुनते हैं, आप शायद प्रभावित हैं। यह वेब सर्वरों, ईमेल सर्वरों, वीपीएन सर्वरों आदि की चिंता करता है। आपको पता चल जाएगा कि आपने एसएसएल को सक्षम कर लिया है क्योंकि आपको एक प्रमाण पत्र जनरेट करना है, या तो एक प्रमाण पत्र पर हस्ताक्षर करने के लिए एक प्रमाणीकरण प्राधिकारी को अनुरोध सबमिट करके या अपने स्वयं के हस्ताक्षर करके। प्रमाण पत्र। (यह संभव है कि कुछ इंस्टॉलेशन प्रक्रिया ने आपको सूचित किए बिना एक स्व-हस्ताक्षरित प्रमाणपत्र उत्पन्न किया हो, लेकिन यह आमतौर पर केवल आंतरिक सर्वरों के लिए किया जाता है, न कि इंटरनेट के संपर्क में आने वाले सर्वरों के लिए।) यदि आप इंटरनेट के संपर्क में आए एक कमजोर सर्वर को चलाते हैं, तो इसे समझौता मानें। जब तक आपके लॉग 2014-04-07 पर घोषणा के बाद से कोई कनेक्शन नहीं दिखाते। (यह मानता है कि इसकी घोषणा से पहले भेद्यता का दोहन नहीं किया गया था।) यदि आपका सर्वर केवल आंतरिक रूप से उजागर हुआ था,
क्लाइंट सॉफ़्टवेयर केवल तभी प्रभावित होता है जब आपने इसे किसी दुर्भावनापूर्ण सर्वर से कनेक्ट करने के लिए उपयोग किया हो। इसलिए यदि आप IMAPS का उपयोग करके अपने ईमेल प्रदाता से जुड़े हैं, तो आपको चिंता करने की आवश्यकता नहीं है (जब तक कि प्रदाता पर हमला नहीं किया गया था - लेकिन अगर ऐसा है तो उन्हें आपको पता होना चाहिए), लेकिन यदि आपने एक असुरक्षित ब्राउज़र के साथ यादृच्छिक वेबसाइटों को ब्राउज़ किया है तो आपको आवश्यकता हो सकती है चिंता करना। अब तक ऐसा लगता है कि खोजे जाने से पहले भेद्यता का दोहन नहीं किया गया था, इसलिए आपको केवल चिंता करने की आवश्यकता है यदि आप 2014-04-08 से दुर्भावनापूर्ण सर्वर से जुड़े हैं।
निम्न प्रोग्राम अप्रभावित हैं क्योंकि वे SSL को लागू करने के लिए OpenSSL का उपयोग नहीं करते हैं:
- SSH (प्रोटोकॉल SSL नहीं है)
- क्रोम / क्रोमियम ( एनएसएस का उपयोग करता है )
- फ़ायरफ़ॉक्स (NSS का उपयोग करता है) (Ubuntu 12.04 पर फ़ायरफ़ॉक्स 27 के साथ कम से कम, लेकिन सभी बिल्ड के साथ नहीं?
प्रभाव क्या है?
बग किसी भी क्लाइंट को अनुमति देता है जो एक बार में सर्वर से 64kB मेमोरी को पुनः प्राप्त करने के लिए आपके एसएसएल सर्वर से जुड़ सकता है। ग्राहक को किसी भी तरह से प्रमाणित करने की आवश्यकता नहीं है। हमले को दोहराने से, ग्राहक क्रमिक प्रयासों में मेमोरी के विभिन्न हिस्सों को डंप कर सकता है। यह संभावित रूप से हमलावर को किसी भी डेटा को पुनर्प्राप्त करने की अनुमति देता है जो सर्वर प्रक्रिया की स्मृति में रहा है, जिसमें चाबियाँ, पासवर्ड, कुकीज़, आदि शामिल हैं।
हमलावरों को पुनर्प्राप्त करने में सक्षम हो सकने वाले डेटा के महत्वपूर्ण टुकड़ों में से एक सर्वर की एसएसएल निजी कुंजी है। इस डेटा के साथ, हमलावर आपके सर्वर को प्रतिरूपित कर सकता है।
बग किसी भी सर्वर को अनुमति देता है जो आपके SSL क्लाइंट को एक बार में क्लाइंट से 64kB मेमोरी को पुनः प्राप्त करने के लिए जुड़ा हुआ है। यह एक चिंता का विषय है यदि आपने संवेदनशील डेटा में हेरफेर करने के लिए एक संवेदनशील ग्राहक का उपयोग किया है और फिर बाद में उसी क्लाइंट के साथ एक अविश्वसनीय सर्वर से जुड़ा है। इस तरफ हमले के परिदृश्य इस प्रकार सर्वर साइड की तुलना में काफी कम हैं।
ध्यान दें कि विशिष्ट वितरणों के लिए, पैकेज वितरण पर कोई सुरक्षा प्रभाव नहीं है क्योंकि पैकेजों की अखंडता जीपीजी हस्ताक्षर पर निर्भर करती है, एसएसएल परिवहन पर नहीं।
मैं भेद्यता को कैसे ठीक करूं?
उजागर सर्वरों का विमोचन
सभी प्रभावित सर्वरों को ऑफ़लाइन ले जाएं। जब तक वे चल रहे हैं, वे संभावित रूप से महत्वपूर्ण डेटा लीक कर रहे हैं।
ओपनएसएसएल लाइब्रेरी पैकेज को अपग्रेड करें । सभी वितरणों को अब तक फिक्स होना चाहिए (या तो 1.0.1g के साथ, या एक पैच के साथ जो संस्करण संख्या को बदले बिना बग को ठीक करता है)। यदि आप स्रोत से संकलित हैं, तो 1.0.1g या इसके बाद के संस्करण पर अपग्रेड करें। सुनिश्चित करें कि सभी प्रभावित सर्वर पुनः आरंभ हो गए हैं।
लिनक्स पर, आप देख सकते हैं कि संभावित रूप से प्रभावित प्रक्रियाएं अभी भी चल रही हैं या नहींgrep 'libssl.*(deleted)' /proc/*/maps
नई कुंजी उत्पन्न करें । यह आवश्यक है क्योंकि बग ने एक हमलावर को पुरानी निजी कुंजी प्राप्त करने की अनुमति दी हो सकती है। उसी प्रक्रिया का पालन करें जिसे आपने शुरू में इस्तेमाल किया था।
- यदि आप एक प्रमाणीकरण प्राधिकारी द्वारा हस्ताक्षरित प्रमाण पत्र का उपयोग करते हैं, तो अपने सीए को अपनी नई सार्वजनिक कुंजी जमा करें। जब आप नया प्रमाणपत्र प्राप्त करते हैं, तो इसे अपने सर्वर पर स्थापित करें।
- यदि आप स्व-हस्ताक्षरित प्रमाण पत्र का उपयोग करते हैं, तो इसे अपने सर्वर पर स्थापित करें।
- किसी भी तरह से, पुराने कुंजियों और प्रमाणपत्रों को बाहर ले जाएं (लेकिन उन्हें हटाएं नहीं, बस यह सुनिश्चित करें कि उन्हें कोई और उपयोग नहीं किया जा रहा है)।
अब जब आपके पास नई असंबद्ध कुंजी हैं, तो आप अपने सर्वर को ऑनलाइन वापस ला सकते हैं ।
पुराने प्रमाण पत्रों को निरस्त करें ।
नुकसान का आकलन : किसी भी डेटा जो एसएसएल कनेक्शन की सेवा करने की प्रक्रिया की स्मृति में रहा है, संभवतः लीक हो सकता है। इसमें उपयोगकर्ता पासवर्ड और अन्य गोपनीय डेटा शामिल हो सकते हैं। आपको यह मूल्यांकन करने की आवश्यकता है कि यह डेटा क्या हो सकता है।
- यदि आप एक ऐसी सेवा चला रहे हैं जो पासवर्ड प्रमाणीकरण की अनुमति देती है, तो भेद्यता की घोषणा से थोड़ा पहले से जुड़े उपयोगकर्ताओं के पासवर्ड को समझौता माना जाना चाहिए। अपने लॉग की जाँच करें और किसी भी प्रभावित उपयोगकर्ता के पासवर्ड बदलें।
- सभी सत्र कुकीज़ को भी अमान्य कर दें, क्योंकि वे समझौता कर सकते थे।
- ग्राहक प्रमाणपत्रों से समझौता नहीं किया जाता है।
- कोई भी डेटा जो भेद्यता से थोड़ा पहले से एक्सचेंज किया गया था, वह सर्वर की मेमोरी में बना रह सकता है और इसलिए किसी हमलावर को लीक किया गया हो सकता है।
- यदि किसी ने एक पुराने एसएसएल कनेक्शन को रिकॉर्ड किया है और आपके सर्वर की कुंजियों को फिर से प्राप्त किया है, तो वे अब अपने ट्रांसक्रिप्ट को डिक्रिप्ट कर सकते हैं। (जब तक कि पीएफएस सुनिश्चित नहीं किया गया था - यदि आप नहीं जानते हैं, तो यह नहीं था।)
अन्य मामलों में बचाव
सर्वर जो केवल लोकलहोस्ट या एक इंट्रानेट पर सुनते हैं, केवल उन पर विचार किया जाना चाहिए, यदि अविश्वासित उपयोगकर्ता उनसे जुड़ सकते हैं।
ग्राहकों के साथ, केवल दुर्लभ परिदृश्य हैं जहां बग का शोषण किया जा सकता है: एक शोषण के लिए आवश्यक होगा कि आप उसी क्लाइंट प्रक्रिया का उपयोग करें
- गोपनीय डेटा (जैसे पासवर्ड, क्लाइंट प्रमाणपत्र,…) में हेरफेर;
- और फिर, उसी प्रक्रिया में, एसएसएल पर एक दुर्भावनापूर्ण सर्वर से जुड़ा हुआ है।
इसलिए उदाहरण के लिए एक ईमेल क्लाइंट जिसे आप केवल अपने (पूरी तरह से अविश्वसनीय नहीं) कनेक्ट करने के लिए उपयोग करते हैं, मेल प्रदाता एक चिंता का विषय नहीं है (दुर्भावनापूर्ण सर्वर नहीं है)। किसी फाइल को डाउनलोड करने के लिए रनिंग वाईज एक चिंता का विषय नहीं है (लीक होने का कोई गोपनीय डेटा नहीं)।
यदि आपने 2014-04-07 की शाम के बीच UTC और अपनी OpenSSL लाइब्रेरी को अपग्रेड किया है, तो किसी भी डेटा पर विचार करें जो क्लाइंट की मेमोरी में समझौता किया जाना था।
संदर्भ