हार्दिक: क्या HTTPS के अलावा अन्य सेवाएं प्रभावित हैं?


65

OpenSSL 'हार्दिक' भेद्यता ( CVE-2014-0160 ) HTTPS की सेवा करने वाले webservers को प्रभावित करता है। अन्य सेवाएँ भी OpenSSL का उपयोग करती हैं। क्या ये सेवाएं भी हार्दिक की तरह डेटा रिसाव की चपेट में हैं?

मैं विशेष रूप से सोच रहा हूँ

  • sshd
  • सुरक्षित SMTP, IMAP आदि - dovecot, exim और postfix
  • वीपीएन सर्वर - ओपेनवोन और दोस्त

सभी, मेरे सिस्टम पर कम से कम, ओपनएसएसएल पुस्तकालयों से जुड़े हुए हैं।


उबंटू के लिए फिक्स: apt-get update && apt-get install Opensl libssl1.0.0 && सर्विस nginx पुनरारंभ; उसके बाद, अपनी निजी कुंजी
होमर

कमजोर मेजबानों का पता लगाने के लिए इस उपकरण का उपयोग करें: github.com/titanous/heartbleeder
Homer6

1
apt-get updateउन्नयन के बिना अब उबंटू के लिए पर्याप्त होना चाहिए, पैच कल रात मुख्य भंडार में दिखाई दिया।
जेसन सी

10
उपयुक्त अद्यतन पर्याप्त नहीं है। अद्यतन केवल नवीनतम परिवर्तन दिखाता है, उपयुक्त- UPGRADE अपडेट के बाद तब लागू होगा।
sjakubowski

1
मुझे यकीन है कि @JasonC का यही मतलब है, लेकिन इसे स्पष्ट रूप से स्पष्ट करने के लिए +1।
क्रेग

जवाबों:


40

कोई भी सेवा जो अपने टीएलएस कार्यान्वयन के लिए ओपनएसएसएल का उपयोग करती है, संभावित रूप से असुरक्षित है; यह अंतर्निहित सीरपोग्राफ़ी लाइब्रेरी में एक कमजोरी है, न कि यह कैसे एक वेब सर्वर या ईमेल सर्वर पैकेज के माध्यम से प्रस्तुत किया जाता है। आपको कम से कम डेटा लीकेज से जुड़ी सभी जुड़ी सेवाओं पर विचार करना चाहिए ।

जैसा कि मुझे यकीन है कि आप जागरूक हैं, यह एक साथ श्रृंखला के हमलों के लिए काफी संभव है। यहां तक ​​कि सरलतम हमलों में भी, यह पूरी तरह से संभव है, उदाहरण के लिए, एसएसएल से समझौता करने के लिए हार्दिक का उपयोग करें, वेबमेल क्रेडेंशियल्स पढ़ें, त्वरित "प्रिय हेल्पडेस्क के साथ अन्य प्रणालियों तक पहुंच प्राप्त करने के लिए वेबमेल क्रेडेंशियल्स का उपयोग करें , क्या आप मुझे $ फू के लिए एक नया पासवर्ड दे सकते हैं, लव सीईओ ”

द हार्टलेड बग में अधिक जानकारी और लिंक हैं , और सर्वर फॉल्ट द्वारा नियमित रूप से बनाए गए एक अन्य प्रश्न में, हार्टलेड: यह क्या है और इसे कम करने के लिए क्या विकल्प हैं?


3
"यह अंतर्निहित प्रणाली में एक कमजोरी है, न कि यह कैसे उच्च स्तर की प्रणाली जैसे एसएसएल / टीएलएस के माध्यम से प्रस्तुत किया जाता है" - नहीं, यह गलत है। यह टीएलएस दिल की धड़कन के विस्तार के कार्यान्वयन में एक कमजोरी है। यदि आप कभी भी टीएलएस का उपयोग नहीं करते हैं तो आप सुरक्षित हैं। मैं आपके निष्कर्ष से सहमत हूं, हालांकि, आपको अपने विश्लेषण में बहुत सावधानी बरतनी होगी कि जंजीरों के हमलों के कारण क्या प्रभावित हो सकता है।
पेर्सीड्स

6
@ पॉडिड्स आप निश्चित रूप से सही हैं, मैं यह कहने का एक आसानी से समझने योग्य तरीका खोजने की कोशिश कर रहा था कि लोग सुरक्षित नहीं हैं क्योंकि वे वेबसर्वर एक्स के इस संस्करण या एसएमटीपी सर्वर वाई के उस संस्करण को चला रहे हैं। मैं एक संपादन कर रहा हूं। उम्मीद है कि चीजों में सुधार होगा, तो यह इंगित करने के लिए धन्यवाद।
रोब मोइर

35

ऐसा लगता है कि आपकी ssh-keys सुरक्षित हैं:

यह इंगित करने योग्य है कि ओपनएसएसएच ओपनएसएसएल बग से प्रभावित नहीं है। जबकि OpenSSH कुछ मुख्य-पीढ़ी के कार्यों के लिए Opensl का उपयोग करता है, यह TLS प्रोटोकॉल का उपयोग नहीं करता है (और विशेष रूप से TLS दिल की धड़कन का विस्तार जो दिल के दौरे को बढ़ाता है)। तो SSH के साथ समझौता किए जाने के बारे में चिंता करने की कोई जरूरत नहीं है, हालांकि अभी भी खुलने का समय अद्यतन करने के लिए 1.0.1g या 1.0.2-Beta2 पर अपडेट करना अच्छा है (लेकिन आपको SSH कीपर्स को बदलने के बारे में चिंता करने की आवश्यकता नहीं है)। - 6 घंटे पहले jimbob डॉ

देखें: https://security.stackexchange.com/questions/55076/what-should-one-do-about-the-heartbleed-openssl-exploit


क्या यह अप्रत्यक्ष रूप से @RobM द्वारा बताए गए तरीके से प्रभावित नहीं है? कोई हार्टबल भेद्यता का उपयोग करके मेमोरी से रूट का पासवर्ड पढ़ता है, सिस्टम में जो भी गैर-एसएसएच एक्सेस प्राप्त करता है और फिर एसएसएच सामान चोरी करता है।
थॉमस वेलर

1
आप इस बग के साथ कोई 64k मेमोरी नहीं पढ़ सकते हैं, केवल 64k के पास जहां आने वाला पैकेट संग्रहीत है। दुर्भाग्यवश बहुत सारी अच्छाइयाँ वहाँ जमा हो जाती हैं, जैसे कि सादे अनुरोधों के साथ डिक्रिप्टेड HTTP अनुरोध, निजी कुंजी और बिल्ली के बच्चे की तस्वीरें।
लार्सर

4

@RobM के उत्तर के अलावा, और जब से आप SMTP के बारे में विशेष रूप से पूछते हैं: SMTP पर बग का दोहन करने के लिए पहले से ही एक PoC है: https://gist.github.com/takeshixx/10107280


4
विशेष रूप से यह टीएलएस कनेक्शन का शोषण करता है जो "स्टार्टटल" कमांड के बाद स्थापित होता है, अगर मैं कोड को सही ढंग से पढ़ता हूं।
पेर्सीड्स

3

यदि वे ओपनएसएसएल पर भरोसा करते हैं, तो उन सेवाओं से समझौता किया जा सकता है

ओपनएसएसएल का उपयोग उदाहरण के लिए ईमेल सर्वर (एसएमटीपी, पीओपी और आईएमएपी प्रोटोकॉल), चैट सर्वर (एक्सएमपीपी प्रोटोकॉल), वर्चुअल प्राइवेट नेटवर्क (एसएसएल वीपीएन), नेटवर्क उपकरणों और क्लाइंट साइड सॉफ्टवेयर की विस्तृत विविधता के लिए किया जाता है।

कमजोरियों, प्रभावित ऑपरेटिंग सिस्टम आदि पर अधिक विस्तृत लिखने के लिए आप http://heartbleed.com/ पर चेकआउट कर सकते हैं।


3

कुछ भी जो लिंक के साथ libssl.soप्रभावित हो सकता है। आपके द्वारा नवीनीकरण के बाद OpenSSL के साथ लिंक करने वाली किसी भी सेवा को पुनः आरंभ करना चाहिए।

# lsof +c 0 | grep -w DEL | awk '1 { print $1 ": " $NF }' | grep libssl | sort -u
bacula-fd: /usr/lib/libssl.so.1.0.0
php-fpm: /usr/lib/libssl.so.1.0.0
php-fpm: /usr/lib/php/modules/openssl.so
python2: /usr/lib/libssl.so.1.0.0
python2: /usr/lib/python2.7/lib-dynload/_ssl.so
python: /usr/lib/libssl.so.1.0.0
ruby-timer-thr: /usr/lib/libssl.so.1.0.0
ruby: /usr/lib/libssl.so.1.0.0

आर्क लिनक्स मेलिंग सूची से अनातोल पोमोज़ोव के सौजन्य से ।


2
कुछ भी जो libssl के साथ लिंक करता है और TLS का उपयोग करता है। Openssh ओपनसेल का उपयोग करता है, लेकिन टीएलएस का उपयोग नहीं करता है, इसलिए यह प्रभावित नहीं होता है।
StasM

2
@StasM यही कारण है कि मैंने लिखा प्रभावित हो सकता है , प्रभावित नहीं है । इसके अलावा, OpenSSH सर्वर OpenSSL के खिलाफ बिल्कुल भी लिंक नहीं करता है। Ssh-keygen जैसी उपयोगिताएँ करती हैं, लेकिन उनका उपयोग OpenSSH सर्वर द्वारा ही नहीं किया जाता है। जो मेरे द्वारा प्रदान किए गए lsof आउटपुट में स्पष्ट रूप से दिखाई देता है - OpenSSH वहां सूचीबद्ध नहीं है, हालांकि यह सर्वर पर चल रहा है।
नोकेर

1

अन्य सेवाएं इससे प्रभावित होती हैं।

जो कोई भी HMailServer का उपयोग करता है, उसके लिए यहां पढ़ना शुरू करें - http://www.hmailserver.com/forum/viewtopic.php?f=7&t=26276

किसी को भी और सभी को अपडेट करने की जरूरत है, यह पता लगाने के लिए सभी सॉफ्टवेयर पैकेज के डेवलपर्स के साथ जांच करने की आवश्यकता होगी।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.