204

यह हार्दिक सुरक्षा के मुद्दे को समझने और हटाने के बारे में एक कैननिकल प्रश्न है ।

वास्तव में CVE-2014-0160 AKA "हार्दिक" क्या है? क्या कारण है, ओपनएसएसएल के कौन से ओएस और संस्करण असुरक्षित हैं, क्या लक्षण हैं, क्या एक सफल शोषण का पता लगाने के लिए कोई तरीके हैं?

मैं यह देखने के लिए कैसे जांच कर सकता हूं कि मेरा सिस्टम प्रभावित है या नहीं? इस भेद्यता को कैसे कम किया जा सकता है? क्या मुझे चिंतित होना चाहिए कि मेरी कुंजी या अन्य निजी डेटा से समझौता किया गया है? मुझे किन अन्य दुष्प्रभावों के बारे में चिंतित होना चाहिए?

security openssl heartbleed

— याकूब
स्रोत

14

Heartbleed के लिए शमन शामिल अधिक सिर्फ नई चाबी से । (सूचना सुरक्षा StackExchange पर मेरे जवाब के लिए लिंक)

— scuzzy-delta

मैं आपको सुनता हूं, लेकिन मुझे लगता है कि ईईएए ने बड़े पैमाने पर नीचे कवर किया है।

— MadHatter

मैं सहमत हूं: यह एक महान जवाब है, लेकिन heartbleed.com यह बताने के लिए बहुत प्रयास करता है कि सिर्फ नए प्रमुख जोड़े से परे विचार हैं - जैसे पासवर्ड परिवर्तन और सत्र अमान्य करना।

— झांझ-डेल्टा

1

@ बदमाश-डेल्टा - अच्छी बात है। मैंने अपना जवाब CW बना दिया है, इसलिए उस जानकारी के साथ इसे संपादित / सुधारने के लिए स्वतंत्र महसूस करता हूं।

— EEAA

3

सबसे अच्छा उदाहरण यह क्या है - (अस्वाभाविक रूप से) XKCD: xkcd.com/1354

— वेन वर्नर

118

सबसे पहले , बाहर निकलने से पहले , सुनिश्चित करें कि आप समझते हैं कि यह भेद्यता वास्तव में आप पर लागू होती है या नहीं। यदि आपके पास एक सर्वर है, लेकिन वास्तव में टीएलएस का उपयोग करने वाला कोई भी एप्लिकेशन नहीं है, तो आपके लिए यह एक उच्च प्राथमिकता वाली चीज नहीं है। यदि, दूसरी ओर, आपके पास कभी टीएलएस-सक्षम अनुप्रयोग होते हैं, तो ठीक है कि आप एक इलाज के लिए हैं। पढ़ते रहिये:

वास्तव में CVE-2014-0160 उर्फ "हार्दिक" क्या है?

यह बहुत बड़ी गड़बड़ है, बस यही है। संक्षेप में, ओपनएसएसएल संस्करणों 1.0.1 के माध्यम से 1.0.1f के माध्यम से एक दूरस्थ रूप से शोषक भेद्यता की खोज की गई थी, जिसके माध्यम से एक हमलावर सिस्टम मेमोरी के कुछ हिस्सों को पढ़ सकता है। उन हिस्सों को जो संवेदनशील डेटा जैसे कि निजी कुंजी, प्रिज़र्ड कीज़, पासवर्ड और उच्च मूल्यवान कॉर्पोरेट डेटा को अन्य चीजों के बीच रखते हैं।

बग को स्वतंत्र रूप से Google सुरक्षा (21 मार्च, 2014) के नील मेहता और फिनिश आईटी सुरक्षा परीक्षण फर्म कोडेनोमिकॉन (2 अप्रैल, 2014) द्वारा खोजा गया था।

कारण क्या है?

खैर, ओपनएसएसएल में गलत कोड। यहाँ वह कमिटमेंट है जिसने भेद्यता को पेश किया है, और यहाँ वह कमिटमेंट है जो भेद्यता को निर्धारित करता है। बग 2011 के दिसंबर में दिखा और आज, 7 अप्रैल 2014 को पैच किया गया।

बग को एक बड़ी समस्या के लक्षण के रूप में भी देखा जा सकता है। दो संबंधित समस्याएं हैं (1) गलत कोड सुनिश्चित करने के लिए कौन सी प्रक्रिया होती है, एक कोड आधार से शुरू नहीं किया जाता है, और (2) प्रोटोकॉल और एक्सटेंशन इतने जटिल और कठिन परीक्षण क्यों हैं। आइटम (1) OpenSSL और कई अन्य परियोजनाओं के साथ एक शासन और प्रक्रिया का मुद्दा है। कई डेवलपर्स बस कोड की समीक्षा, विश्लेषण और स्कैनिंग जैसी प्रथाओं का विरोध करते हैं। आइटम (2) पर IETF के TLS WG पर चर्चा की जा रही है। हार्दिक / प्रोटोकॉल जटिलता देखें ।

क्या गलत कोड गलत तरीके से डाला गया था?

मैं इस बात पर अटकल नहीं लगाऊंगा कि यह वास्तव में एक गलती थी या संभवतः एक बुरे अभिनेता की ओर से थोड़ा सा कोड फिसल गया। हालाँकि, OpenSSL के लिए कोड विकसित करने वाला व्यक्ति यह बताता है कि वह अनजाने में था। देखें मैन जिन्होंने गंभीर 'हार्दिक' सुरक्षा दोष का परिचय दिया, उन्होंने इनकार किया कि उन्होंने इसे जानबूझकर डाला ।

ओपनएसएसएल के कौन से ओएस और संस्करण असुरक्षित हैं?

जैसा कि ऊपर उल्लेख किया गया है, कोई भी ऑपरेटिंग सिस्टम जो प्रयोग कर रहा है, या एप्लिकेशन जो OpenSSL 1.0.1 के माध्यम से 1.0.1f से जुड़ा हुआ है।

लक्षण क्या हैं, एक सफल शोषण का पता लगाने के लिए कोई भी तरीके हैं?

यह डरावना हिस्सा है। जहां तक हम जानते हैं, यह पता लगाने का कोई ज्ञात तरीका नहीं है कि इस भेद्यता का दोहन किया गया है या नहीं। यह सैद्धांतिक रूप से संभव है कि आईडीएस हस्ताक्षर जल्द ही जारी किए जाएंगे जो इस शोषण का पता लगा सकते हैं, लेकिन इस लेखन के रूप में, वे उपलब्ध नहीं हैं।

इस बात के प्रमाण हैं कि हार्टलेड का नवंबर, 2013 की शुरुआत में जंगल में सक्रिय रूप से शोषण किया जा रहा था। ईएफएफ के वाइल्ड एट हार्ट: नवंबर 2013 में हार्टलेड का उपयोग करते हुए खुफिया एजेंसियों का पता लगाया गया था? और ब्लूमबर्ग ने रिपोर्ट की कि भेद्यता शुरू होने के कुछ समय बाद ही एनएसए ने शोषण को हथियार बना लिया था। देखें साल के लिए खुफिया के लिए Heartbleed बग शोषण करने के लिए एनएसए ने कहा । हालांकि, यूएस इंटेलिजेंस कम्युनिटी ने ब्लूमबर्ग के दावों को नकार दिया है। रिकॉर्ड को देखें ।

मैं यह देखने के लिए कैसे जांच कर सकता हूं कि मेरा सिस्टम प्रभावित है या नहीं?

यदि आप अपने सिस्टम पर OpenSSL का रखरखाव कर रहे हैं, तो आप बस जारी कर सकते हैं openssl version:

$ openssl version
OpenSSL 1.0.1g 7 Apr 2014

यदि वितरण OpenSSL को बनाए रखने की है, तो आप शायद OpenSSL के संस्करण को वापस का उपयोग कर पैचिंग के कारण निर्धारित नहीं कर सकता opensslआदेश या पैकेज जानकारी (उदाहरण के लिए, apt-get, dpkg, yumया rpm)। अधिकांश (सभी?) वितरणों द्वारा उपयोग की जाने वाली बैक पैचिंग प्रक्रिया केवल आधार संस्करण संख्या (उदाहरण के लिए, "1.0.1e") का उपयोग करती है; और एक प्रभावी सुरक्षा संस्करण शामिल नहीं है (उदाहरण के लिए, "1.0.1g")।

पैकेज के बैकपैक किए जाने पर ओपनएसएसएल और अन्य पैकेजों के लिए प्रभावी सुरक्षा संस्करण का निर्धारण करने के लिए सुपर उपयोगकर्ता पर एक खुला प्रश्न है। दुर्भाग्य से, कोई उपयोगी उत्तर नहीं हैं (डिस्ट्रो की वेबसाइट की जांच के अलावा)। देखें निर्धारित प्रभावी सुरक्षा संस्करण जब Backpatching का सामना करना पड़ ।

अंगूठे के एक नियम के रूप में: यदि आपने कभी प्रभावित संस्करणों में से एक को स्थापित किया है, और कभी भी ऐसे प्रोग्राम या सेवाएं चला रहे हैं जो टीएलएस समर्थन के लिए ओपनएसएसएल के खिलाफ जुड़े हैं, तो आप कमजोर हैं।

मुझे भेद्यता के लिए परीक्षण करने के लिए एक कार्यक्रम कहां मिल सकता है?

हार्दिक घोषणा के कुछ घंटों के भीतर, इंटरनेट पर कई लोगों ने सार्वजनिक रूप से सुलभ वेब अनुप्रयोगों को प्रचारित किया था जो कि इस भेद्यता की उपस्थिति के लिए सर्वर की जांच करने के लिए उपयोग किए जा सकते थे। इस लेखन के रूप में, मैंने किसी की समीक्षा नहीं की है, इसलिए मैं उनके अनुप्रयोगों को आगे प्रचारित नहीं करूंगा। वे आपके पसंदीदा खोज इंजन की सहायता से अपेक्षाकृत आसानी से पाए जा सकते हैं।

इस भेद्यता को कैसे कम किया जाता है?

एक गैर-असुरक्षित संस्करण पर अपग्रेड करें और असुरक्षित डेटा को रीसेट या फिर से सुरक्षित करें। जैसा कि हार्टबल साइट पर लिखा गया है , उचित प्रतिक्रिया के कदम मोटे तौर पर हैं:

पैच कमजोर सिस्टम।
नई निजी कुंजियों को पुन: बनाएँ।
अपने सीए को नया सीएसआर जमा करें।
नया हस्ताक्षरित प्रमाणपत्र प्राप्त करें और स्थापित करें।
सत्र कुंजियाँ और कुकीज़ अमान्य करें
पासवर्ड और साझा किए गए रहस्यों को रीसेट करें
पुराने प्रमाण पत्रों को निरस्त करें।

अधिक विस्तृत विश्लेषण और उत्तर के लिए, देखें कि हार्टलेड ओपनएसएसएल कारनामे के बारे में एक वेबसाइट ऑपरेटर को क्या करना चाहिए? सुरक्षा स्टैक एक्सचेंज पर।

क्या मुझे चिंतित होना चाहिए कि मेरी कुंजी या अन्य निजी डेटा से समझौता किया गया है? मुझे किन अन्य दुष्प्रभावों के बारे में चिंतित होना चाहिए?

पूर्ण रूप से। सिस्टम एडमिनिस्ट्रेटर को यह मानने की जरूरत है कि उनके सर्वर जो असुरक्षित ओपनएसएसएल संस्करणों का उपयोग करते थे, वे वास्तव में समझौता करते हैं और तदनुसार प्रतिक्रिया करते हैं।

भेद्यता का खुलासा होने के तुरंत बाद, क्लाउडफ़ ने एक चुनौती पेश की कि क्या सर्वर की निजी कुंजी को व्यवहार में पुनर्प्राप्त किया जा सकता है। चुनौती को स्वतंत्र रूप से फेडर इंडटनी और इल्का मटिला ने जीता। देखें Heartbleed चैलेंज ।

मुझे अधिक जानकारी कहां से मिल सकती है?

लिंक डंप, अधिक जानकारी के लिए देख रहे लोगों के लिए:

प्रकटीकरण घटनाओं की एक विस्तृत समयरेखा हार्टलेड प्रकटीकरण समयरेखा पर पाई जा सकती है : कौन क्या और कब जानता था ।

यदि आप एक प्रोग्रामर हैं और विभिन्न प्रोग्रामिंग ट्रिक्स में रुचि रखते हैं, जैसे ओपनएसएसएल के msg_cbकॉलबैक के माध्यम से हार्टबल हमले का पता लगाने के लिए , तो ओपनएसएसएल की सुरक्षा सलाहकार 2014047 देखें ।

— रेव्स , 3 उपयोगकर्ता 60% user145545
स्रोत

42

SHUT के लिए +1 । नीचे। तुम्हारी। सर्वर। * - यदि आप कुछ भी करते हैं जहां एसएसएल वास्तव में महत्वपूर्ण है, तो समस्या को ठीक करने तक इसे बंद कर दें। अपने सर्वर्स को पैच करने के बाद नए सर्टिफिकेट्स ( नई चाबियों के साथ ) स्थापित करना न भूलें - अपनी पुरानी कुंजियों (जिसका समझौता हो सकता है) का पुन: उपयोग करके भेद्यता को पैच करने के पूरे उद्देश्य को हरा देता है ...

— voretaq7

29

ALSO - OpenSSL पुस्तकालयों से जुड़ी किसी भी सेवा को पुनः आरंभ करें। अपने डायमनों को फिर से शुरू किए बिना ओपनएसएसएल को अपग्रेड करना उतना ही अच्छा है जितना कि अपग्रेड न करना।

— EEAA

14

वास्तव में - किसी भी तरह के प्रमुख पैच (जैसे ओपनएसएसएल) के बाद, मैं यह सुनिश्चित करने के लिए मशीन को रिबूट करने के लिए एक अच्छा नियम मानता हूं कि आप कुछ भी याद नहीं करते हैं।

— voretaq7

5

परीक्षकों में से एक खुला-

— खट्टा हो चुका है

3

@ EEAA, "अपने सर्वर को शटडाउन करें" इसका मतलब यह नहीं है कि आपको पावर खींचना है। इसका मतलब है शट डाउन (या ssl / tls को निष्क्रिय करने के लिए पुन: कॉन्फ़िगर करें) या जो भी सेवा कर रहा है।

— Psusi

42

XKCD द्वारा बग का एक सरल विवरण:

— रिवीजन 200_success
स्रोत

36

Ubuntu 12.04, 12.10 और 13.10

उबंटू ने USN-2165-1 जारी किया है , जिसमें कहा गया है कि अद्यतन पैकेज अब अभिलेखागार में उपलब्ध हैं। फिक्स को हथियाने के लिए निम्नलिखित दो कमांड चलाएं।

sudo apt-get update
sudo apt-get upgrade

उबंटू 14.04

मैंने एक डेबियन पैकेज अपलोड किया है जिसमें नई रिलीज़ (1.0.1g) एक पीपीए के लिए है जिसे मैंने इस उद्देश्य के लिए स्थापित किया है। ये तीन कमांड मेरे PPA को आपके सिस्टम में जोड़ देंगे, उपलब्ध पैकेज की सूची को अपडेट करेंगे और सब कुछ अपग्रेड करेंगे:

sudo add-apt-repository ppa:george-edison55/openssl-heartbleed-fix
sudo apt-get update
sudo apt-get upgrade

_{नोट: PPA भी उबंटू 12.04 और 13.10 के लिए पैकेज प्रदान करता है, सिर्फ अगर आप अभिलेखागार में पैच किए गए संस्करणों का उपयोग करने के बजाय वास्तव में नया संस्करण (1.0.1g) चलाना पसंद करते हैं।}

उबंटू 10.04

यह एक एलटीएस संस्करण है, सर्वर संस्करण अभी भी समर्थित है और सुरक्षा अपडेट प्राप्त करता है। लेकिन हार्दिक भेद्यता ubuntu 10.04 के मानक इंस्टॉलेशन के ओपनसेल पैकेज को प्रभावित नहीं करती थी, क्योंकि संस्करण 1.0.1 से नीचे है।

डेस्कटॉप संस्करण जीवन के अंत तक पहुंच गया है और इसे उन्नत / पुनः इंस्टॉल करने की आवश्यकता है।

Ubuntu 13.04 और अन्य पुराने संस्करण

Ubuntu 13.04 में एक बहुत ही कम समर्थन चक्र था जिसकी आपको उम्मीद नहीं थी। यह पहले से ही जीवन के अंत तक पहुंच गया है और सुरक्षा अद्यतन प्राप्त नहीं करता है। इसे लंबे समय तक अपग्रेड किया जाना चाहिए था। अगर अभी भी कोई इसे इस्तेमाल कर रहा है, तो कृपया इसे अपग्रेड करें, या तो इसे स्क्रैच से अपग्रेड किया जा सकता है या इसे नॉन-डिस्ट्रक्टिव में 13.10 पर अपग्रेड किया जा सकता है: http://www.tecmint.com/upgrad-ubuntu-13-04-raring-ringtail -to-ubuntu-13-10-saucy-salamander / उन्नयन के बाद प्रणाली 13.10 से हार्दिक पैच प्राप्त करती है।

अन्य सभी पुराने ऑबंटू संस्करणों के लिए इसका मतलब है कि मूल रूप से एक ताजा स्थापना आवश्यक है।

सत्यापित करें कि पैच लागू किया गया था

अनिवार्य रूप से, चलाएं openssl version -aऔर सुनिश्चित करें कि बिल्ड की तारीख 7 अप्रैल 2014 या उसके बाद है, लेकिन यहां और देखें ।

रीबूट

ओपनएसएसएल पर निर्भर सभी सेवाओं को फिर से शुरू करने के लिए सुनिश्चित करने का सबसे अच्छा तरीका रिबूट है ।

— नाथन उस्मान
स्रोत

मैं अन्य संस्करणों के लिए बात नहीं कर सकता, लेकिन सटीक (12.04) के लिए उपलब्ध पैच प्रतीत होता है। हालांकि मैं कुछ के लिए यह नहीं कह सकता कि यह भेद्यता को ठीक करता है, यह कम से कम संबंधित प्रतिबद्ध ( Mon Apr 7 20:31:55 UTC 2014) के बाद संकलित किया गया था ।

— कैल्रॉन

@ कैरलियन: ओपनएसएसएल के लिए एक पैच या ओपनएसएसएल के लिए डेबियन पैकेजिंग? ओपनएसएसएल पहले से ही तय किया गया है और एक नई रिलीज जारी की गई है।

— नाथन उस्मान

मौजूदा कनेक्शनों का क्या होगा जबकि Opensl को अपडेट किया जा रहा है? क्या उन्हें छोड़ा जाएगा?

— pdeva

2

यह निर्भर करता है कि आप किस वेब सर्वर का उपयोग कर रहे हैं और आप कैसे अपडेट करते हैं। कहा जा रहा है, मैं मौजूदा कनेक्शन को छोड़ने के बारे में चिंता नहीं करूंगा क्योंकि वे कमजोर संस्करण का उपयोग कर रहे हैं।

— नाथन उस्मान

3

14.04 के बाद से एक पैच प्राप्त हुआ है ।

— सेठ

14

RedHat 6.5 और CentOS 6.5

ये कमजोर हैं। RedHat के इरेटा RHSA-2014-0376 का कहना है कि पैच लाइब्रेरी उपलब्ध हैं, और प्रभावित किसी व्यक्ति को जल्द से जल्द अवसर पर अपग्रेड करना चाहिए।

लेखन के समय, CentOS का अभी कोई निश्चित संस्करण नहीं था, लेकिन करनबीर सिंह की CentOS- घोषणा के लिए पोस्टिंग में कहा गया है कि उन्होंने खुलने वाले संस्करण का एक अद्यतन संस्करण तैयार किया है ( openssl-1.0.1e-16.el6_5.4.0.1, अंतिम चार अंकों पर ध्यान दें जो महत्वपूर्ण हैं) शोषक TLS है अक्षम किया गया, और इसे सुरक्षित रूप से लागू किया जा सकता है क्योंकि यह एक निश्चित संस्करण द्वारा अधिलेखित हो जाएगा जब इसे अंततः जारी किया जाएगा।

अस्थायी रूप से तय किया गया संस्करण अभी तक सभी दर्पणों पर नहीं बना है, लेकिन http://mirror.centos.org/centos/6/updates/x86_64/Packages/ (और इसी तरह के लिए मुख्य भंडार में है) i686)।

संपादित करें : जैसा कि इयान कहते हैं, अब C6.5 के लिए एक पूरी तरह से पैचेड संस्करण प्रतीत होता है, और यह जल्दबाज़ी में दर्पणों के आसपास धकेल दिया गया लगता है। एक सीधे yum updateमेरे सर्वर के लिए मिल गया; यह है openssl-1.0.1e-16.el6_5.7।

6.5 से पहले आरएच 6 और सी 6 के संस्करण

ये असुरक्षित नहीं हैं। Red Hat की इस सलाह के अनुसार ,

Red Hat Enterprise Linux 5 और Red Hat Enterprise Linux 6.4 और इससे पहले के संस्करण के रूप में इस समस्या ने Opensl के संस्करणों को प्रभावित नहीं किया।

करनबीर सिंह की CentOS- घोषणा की पोस्टिंग संस्करण के बारे में समान रूप से स्पष्ट है:

इससे पहले आज दिन में, हमें ओपनसीएल में एक गंभीर मुद्दे के बारे में अवगत कराया गया था जैसा कि CentOS-6.5 में भेज दिया गया है

— मैड हैटर
स्रोत

क्या lists.centos.org/pipermail/centos-announce/2014-April/… फिक्स की रिलीज़ नहीं है ?

— user619714

13

डेबियन व्हीज़ी

डेबियन ने डीएसए -2896-1 को अलग कर दिया है और यहां पैच लाइब्रेरी उपलब्ध हैं । एक शेल स्क्रिप्ट यहां उपलब्ध है ।

1. पैच

Apt-get repository को अपडेट किया गया था ताकि अब पैच किए गए लाइब्रेरी के माध्यम से उपलब्ध हों apt-get update && apt-get upgrade

apt-get upgrade libssl1.0.0 openssl

वैकल्पिक रूप से (अनुशंसित नहीं) पैकेजों को मैन्युअल रूप से अपग्रेड किया जा सकता है:

wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/openssl_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_1.0.1e-2+deb7u5_amd64.deb

dpkg -i openssl_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl-dev_1.0.1e-2+deb7u5_amd64.deb

2. सर्वर / सेवाओं को पुनरारंभ करें

सर्वोत्तम सुरक्षा के लिए पूरे सर्वर को पुनरारंभ करें या यदि सर्वर ऑफ़लाइन नहीं हो सकता है तो आवश्यक सेवाओं को पुनरारंभ करें।

3. ओपनएसएसएल संस्करण की जाँच करें

love@server:~$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
love@server:~$ dpkg -l libssl1.0.0
||/ Name                    Version          Architecture     Description
+++-=======================-================-================-====================================================
ii  libssl1.0.0                 1.0.1e-2+deb7u6  amd64            SSL shared libraries

— jacksoncage
स्रोत

1

यदि आपको अपडेट मिल रहा है wheezy/securityतो आप के साथ अच्छा होगा apt-get update && apt-get upgrade। या, केवल संकुल अद्यतन करने के लिए एक इंटरैक्टिव पैकेज मैनेजर उपयोग openssl, libssl1.0.0, libssl1.0.0-dbgऔर libssl-dev(के रूप में आपके सिस्टम पर स्थापित)।

— एक CVn

apt-get का उपयोग करना मेरे लिए समस्या को ठीक नहीं करता है - फिर भी OpenSSL 1.0.1e 11 फरवरी 2013 दिखा रहा है

— user568829

धन्यवाद @ michael-kjorling, यह तब उपलब्ध नहीं था जब मैंने ऐसा किया था, लेकिन यह अपग्रेड करने का सबसे सुरक्षित और सही तरीका है।

— जैकसनसीज

2

@ user568829 पैच ओपनसेल संस्करण को लागू करने के बाद भी दिखाई देगा OpenSSL 1.0.1e 11 Feb 2013क्योंकि पैच को 1.0.1e-2 कहा जाता है। आप के साथ देख सकते हैं dpkg -l opensslऔर यह संस्करण दिखाना चाहिए1.0.1e-2+deb7u6

— jacksoncage

2

मैं ओपनएसएसएल को अपडेट करने के बाद होस्ट को फिर से शुरू करने का सुझाव देता हूं, इसलिए नहीं कि यह कड़ाई से आवश्यक है, बल्कि मन की शांति के लिए है कि ओपनएसएसएल पुस्तकालयों को गतिशील रूप से लोड करने वाले कम से कम सब कुछ नए संस्करण का उपयोग कर रहा है। (स्टेटिक रूप से जुड़ा हुआ एक और मामला है।) उस ने कहा, मैं मानता हूं कि कुछ सर्वर आसानी से उन सभी स्थितियों में रिबूट नहीं किए जा सकते हैं जहां एक सेवा पुनरारंभ स्वीकार्य हो सकता है।

— बजे एक CVn

9

मैं यह बताना चाहता हूं कि निजी कुंजी केवल संपत्ति नहीं है जिसे समझौता माना जाना चाहिए। बग में किसी भी मेमोरी को उसी एड्रेस स्पेस (यानी, उसी प्रक्रिया) में ओपनएसएसएल के रूप में चलाने की क्षमता है । इसलिए, यदि आप एक सर्वर प्रक्रिया चला रहे हैं, जहां ओपनएसएसएल का एक कमजोर संस्करण सांख्यिकीय या गतिशील रूप से जुड़ा हुआ है, तो उस प्रक्रिया का कोई भी टुकड़ा जो कभी भी संभाला जाता है , जिसमें पासवर्ड, क्रेडिट कार्ड नंबर और अन्य व्यक्तिगत डेटा शामिल हैं, को संभावित रूप से समझौता माना जाना चाहिए।

— 200_success
स्रोत

9

FreeBSD 10.0 या बंदरगाहों से खुलता है

FreeBSD सुरक्षा टीम : CVE-2014-0160 (उर्फ "Heartbleed") और के बारे में एक सलाह जारी की है FreeBSD-SA-14: 06.openssl

FreeBSD को अपडेट करना
- बाइनरी पैच के माध्यम से फ्रीबीएसडी को अपडेट करना
  
  I386 या amd64 प्लेटफॉर्म पर FreeBSD के RELEASE संस्करण को चलाने वाले सिस्टम को freebsd-update (8) उपयोगिता के माध्यम से अपडेट किया जा सकता है:
```
# freebsd-update fetch
# freebsd-update install
```
- स्रोतों से फ्रीबीएसडी को अद्यतन करना
  1. नीचे दिए गए स्थान से संबंधित पैच डाउनलोड करें, और अपनी PGP उपयोगिता का उपयोग करके अलग किए गए PGP हस्ताक्षर को सत्यापित करें।
```
# fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch
# fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch.asc
# gpg --verify openssl-10.patch.asc
```
  2. निम्नलिखित कमांड को रूट के रूप में निष्पादित करें:
```
# cd /usr/src
# patch < /path/to/patch
```
  3. ऑपरेटिंग सिस्टम को फिर से व्यवस्थित करें
    
    बिल्डवर्ल्ड और इंस्टॉलवर्ल्ड का उपयोग करना जैसा कि FreeBSD हैंडबुक में वर्णित है ।
अद्यतन openssl न्यूनतम संस्करण के साथ पोर्ट 1.0.1_10
लाइब्रेरी का उपयोग करके सभी डेमों को पुनरारंभ करें, या सिस्टम को रिबूट करें
ऐसा मानें कि आपकी प्रणाली से छेड़छाड़ की गई है, अपने सभी ssl कुंजियों और / या प्रमाणपत्रों को फिर से जारी करें और संभावित रूप से लीक की गई जानकारी देखें ( EEAA अधिक सामान्य उत्तर देखें)।

FreeBSD 9.x और FreeBSD 8.x

ये सिस्टम डिफ़ॉल्ट रूप से हार्टलेड इश्यू के लिए असुरक्षित नहीं है , क्योंकि ओपनश्ल लाइब्रेरी के पुराने 0.9.x संस्करण पर निर्भर करता है , जब तक कि आप पोर्ट्स ( ओपनस्टेयर देखें) से ओपनसेल इंस्टॉल नहीं करते ।

यदि ये सिस्टम हार्टलेड इश्यू के लिए असुरक्षित नहीं हैं , तो हो सकता है कि किसी अन्य स्थानीय भेद्यता के कारण आपके सिस्टम को जल्द से जल्द अपग्रेड करना आसान हो (देखें FreeBSD-SA-14: 06.openssl और "FreeBSD 10.0- खंड ऊपर):

एक स्थानीय हमलावर एक हस्ताक्षर करने की प्रक्रिया को सूंघने में सक्षम हो सकता है और इससे हस्ताक्षर कुंजी को पुनर्प्राप्त कर सकता है। [CVE-2014-0076]

नोट :

मूल हार्दिक सलाहकार फ्रीबीएसडी 8.4 और 9.1 को संभावित रूप से कमजोर होने के रूप में सूचीबद्ध करता है। हार्टबीट एक्सटेंशन की कमी (डिफ़ॉल्ट FreeBSD Opensl लाइब्रेरी का संस्करण 0.9.x है) की कमी के कारण यह सही नहीं है ।

— Ouki
स्रोत

3

मैंने पाया कि इसके साथ काम करने वाले कई उपकरणों पर SSL के संस्करणों को निर्धारित करना असंभव है। यद्यपि यह तकनीकी रूप से शमन नहीं है, लेकिन वर्तमान में कमजोर मेजबानों को पहचानने में सक्षम होना मेरी सूची में सबसे ऊपर था।

मैंने एक छोटे वीएम को एक साथ रखा है जो फिलोसॉटिल के परीक्षण मॉड्यूल का उपयोग करके मनमाने मेजबानों और बंदरगाहों के खिलाफ जांच करेगा । प्रारंभिक नज़र में कोड ध्वनि दिखता है।

पूर्ण VM की रिलीज़ यहाँ है । यह VMX प्रारूप में है।

चेतावनी के शब्द

यह स्क्रिप्ट और VM केवल आपके सिस्टम की वर्तमान स्थिति दिखाएगा। यह पूरी तरह से संभव है कि अतीत में किसी बिंदु पर आपके सिस्टम एक कमजोर स्थिति में थे और दुरुपयोग किया जा सकता था।

यहाँ कुछ दिखाना निश्चित रूप से तय करने के लिए एक उच्च प्राथमिकता है, लेकिन यह आपको अपडेट लागू करने और अपनी सभी कुंजियों को बदलने के लिए हुक से नहीं मिलता है।

— टिम ब्रिघम
स्रोत

मुझे सिर्फ Snapt से एक ईमेल मिला है, यह उनका है। BOLO (लुकआउट पर) !

— जैकब

2

Amazon Linux (अमेज़न EC2 में इस्तेमाल किया जाने वाला लिनक्स डिस्ट्रो)

https://aws.amazon.com/amazon-linux-ami/security-bulletins/ALAS-2014-320/

अंक अवलोकन: ओपनएसएसएल ने टीएलएस दिल की धड़कन के विस्तार पैकेट को संभालने के तरीके में एक लापता सीमा की जाँच की। इस दोष का उपयोग कनेक्टेड क्लाइंट या सर्वर से 64k तक मेमोरी को प्रकट करने के लिए किया जा सकता है।

प्रभावित संस्करण: कोई भी अमेज़ॅन लिनक्स एएमआई जिस पर ओपनएसएल 1.0.1 स्थापित है, जो कि किसी भी अमेज़ॅन लिनक्स एएमआई 2013.03 या बाद में है, और कोई भी अमेज़ॅन लिनक्स एएमआई जो 2013.03 या बाद में अपग्रेड हो गया है। ओपनएसएसएल अमेजन लिनक्स एएमआई पर डिफ़ॉल्ट रूप से स्थापित है।

प्रभावित पैकेज: खुलता है

समस्या सुधार: अपने सिस्टम को अपडेट करने के लिए yum अपडेट को ओपन करता है। एक बार नया पैकेज स्थापित हो जाने के बाद, यह आवश्यक है कि आप या तो मैन्युअल रूप से उन सभी सेवाओं को पुनः आरंभ करें, जो कि ओपनसीएल का उपयोग कर रही हैं, या आप अपने उदाहरण को रिबूट करते हैं। जबकि नए पैकेज का नाम अभी भी ओपनएसएल-डीवाईई है, इसमें सीवीई-2014-0160 के लिए फिक्स शामिल हैं।

नए पैकेज: i686:

openssl-1.0.1e-37.66.amzn1.i686

openssl-static-1.0.1e-37.66.amzn1.i686

openssl-perl-1.0.1e-37.66.amzn1.i686

openssl-devel-1.0.1e-37.66.amzn1.i686

openssl-debuginfo-1.0.1e-37.66.amzn1.i686

x86_64:

openssl-devel-1.0.1e-37.66.amzn1.x86_64

openssl-1.0.1e-37.66.amzn1.x86_64

openssl-debuginfo-1.0.1e-37.66.amzn1.x86_64

openssl-perl-1.0.1e-37.66.amzn1.x86_64

openssl-static-1.0.1e-37.66.amzn1.x86_64

— गैरेथ मैकडैड
स्रोत

हार्दिक: यह क्या है और इसे कम करने के लिए क्या विकल्प हैं?