टी एल; डॉ
शेलशॉक भेद्यता पूरी तरह से तय हो गई है
- बैश 2.05b शाखा पर: 2.05b.10 और ऊपर (पैच 10 शामिल)
- बैश 3.0 शाखा पर: 3.0.19 और उससे अधिक (पैच 19 शामिल)
- बैश-3.1 शाखा पर: 3.1.20 और ऊपर (पैच 20 शामिल)
- बैश -3.5 शाखा पर: 3.2.54 और उससे अधिक (पैच 54 शामिल)
- बैश -4.0 शाखा पर: 4.0.41 और उससे अधिक (पैच 41 शामिल)
- बैश-4.1 शाखा पर: 4.1.14 और उससे अधिक (पैच 14 शामिल)
- बैश -4.5 शाखा पर: 4.2.50 और उससे अधिक (पैच 50 शामिल)
- बैश-4.3 शाखा पर: 4.3.27 और उससे अधिक (पैच 27 शामिल)
यदि आपका बैश एक पुराना संस्करण दिखाता है, तो आपका OS विक्रेता अभी भी इसे अपने आप से पैच कर सकता है, इसलिए सबसे अच्छा है जांच करना।
अगर:
env xx='() { echo vulnerable; }' bash -c xx
"कमजोर" दिखाता है, आप अभी भी कमजोर हैं। यह एकमात्र परीक्षण है जो प्रासंगिक है (चाहे बैश पार्सर अभी भी किसी भी पर्यावरण चर में कोड के संपर्क में है )।
विवरण।
बग समारोह / 5 पर शुरू की आयात, निर्यात की प्रारंभिक क्रियान्वयन में था वें ब्रायन फॉक्स द्वारा अगस्त 1989 की है, और पहले बैश-1.03 में एक महीने के बारे में बाद में एक समय जहां पार्टी इस तरह के बड़े पैमाने पर इस्तेमाल में नहीं था पर जारी की है, सुरक्षा से पहले यह एक चिंता का विषय था और HTTP और वेब या लिनक्स भी मौजूद थे।
1.05 में चेंजलॉग से :
Fri Sep 1 18:52:08 1989 Brian Fox (bfox at aurel)
* readline.c: rl_insert (). Optimized for large amounts
of typeahead. Insert all insertable characters at once.
* I update this too irregularly.
Released 1.03.
[...]
Sat Aug 5 08:32:05 1989 Brian Fox (bfox at aurel)
* variables.c: make_var_array (), initialize_shell_variables ()
Added exporting of functions.
उस समय के आसपास gnu.bash.bug और comp.unix.quest में कुछ चर्चाएँ भी सुविधा का उल्लेख करती हैं।
यह समझना आसान है कि यह वहां कैसे पहुंचा।
bash env vars में फंक्शन्स को एक्सपोर्ट करता है
foo=() {
code
}
और आयात पर, यह सब करना है कि =एक अंतरिक्ष के साथ प्रतिस्थापित किया गया है ... इसके अलावा इसे नेत्रहीन व्याख्या नहीं करनी चाहिए।
इसमें यह भी टूटा हुआ है bash(बॉर्न शेल के विपरीत), स्केलर चर और कार्यों का एक अलग नाम स्थान है। असल में अगर आपके पास है
foo() { echo bar; }; export -f foo
export foo=bar
bash खुशी से दोनों को पर्यावरण में डाल देगा (हाँ एक ही चर नाम के साथ प्रविष्टियाँ), लेकिन कई उपकरण (कई गोले सहित) उन्हें प्रचारित नहीं करेंगे।
एक यह भी तर्क देगा कि बैश को इसके लिए एक BASH_नामस्थान उपसर्ग का उपयोग करना चाहिए , क्योंकि यह केवल एनएवी संस्करण है जो बैश से बैश तक प्रासंगिक है। एक समान सुविधा के लिए rcएक fn_उपसर्ग का उपयोग करता है ।
इसे लागू करने का एक बेहतर तरीका सभी निर्यातित चर की परिभाषा को एक चर में रखना होगा:
BASH_FUNCDEFS='f1() { echo foo;}
f2() { echo bar;}...'
यह अभी भी sanitized की जरूरत है, लेकिन कम से कम है कि $BASH_ENVया से अधिक शोषण नहीं हो सकता है $SHELLOPTS...
वहाँ एक पैच है जो bashफ़ंक्शन परिभाषा के अलावा और कुछ की व्याख्या करने से रोकता है ( https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00081.html ), और वह एक है विभिन्न लिनक्स वितरण से सभी सुरक्षा अपडेट में लागू किया गया है।
हालाँकि, बैश अभी भी कोड की व्याख्या करता है और दुभाषिया में किसी भी बग का शोषण किया जा सकता है। ऐसा एक बग पहले ही मिल चुका है (CVE-2014-7169) हालांकि इसका प्रभाव बहुत कम है। इसलिए जल्द ही एक और पैच आने वाला है।
जब तक किसी भी वैरिएबल में कोड को व्याख्या करने के लिए बैश को रोक देने वाला एक सख्त निर्धारण नहीं होता (जैसे BASH_FUNCDEFSऊपर दिए गए दृष्टिकोण का उपयोग करना ), हमें यह निश्चित रूप से पता नहीं चलेगा कि क्या हम बैश पार्सर में बग से कमजोर नहीं हैं। और मुझे विश्वास है कि जल्द या बाद में इस तरह का एक सख्त निर्धारण जारी किया जाएगा।
2014-09-28 को संपादित करें
पार्सर में दो अतिरिक्त कीड़े पाए गए हैं (CVE-2014-718 {6,7}) (ध्यान दें कि ज्यादातर गोले कोने के मामलों के लिए उनके पार्सर में कीड़े होने के लिए बाध्य हैं, अगर उस पार्सर ने यह चिंता नहीं की होगी। 'अविश्वसनीय डेटा से अवगत कराया गया है)।
जबकि सभी 3 बग 7169, 7186 और 7187 पैच के बाद तय किए गए हैं, रेड हैट ने सख्त निर्धारण के लिए धक्का दिया। अपने पैच में, उन्होंने व्यवहार को बदल दिया ताकि फ़ंक्शन को चर में निर्यात किया जाए जिसे BASH_FUNC_myfunc()चेत के डिजाइन निर्णय को कम या ज्यादा बताया गया था।
चेट ने बाद में प्रकाशित किया कि एक आधिकारिक अपस्ट्रीम बैश पैच के रूप में ठीक करें ।
यह सख्त पैच, या इसके प्रकार अब अधिकांश प्रमुख लिनक्स वितरण के लिए उपलब्ध हैं और अंततः इसे Apple OS / X के लिए बनाया गया है।
अब पार्सर में दो अन्य भेद्यताओं (सीवीई-2014-627 {7,8}) सहित उस वेक्टर के माध्यम से पार्सर का शोषण करने वाले किसी भी मनमाने तरीके से एनवी संस्करण के लिए चिंता का विषय है कि बाद में खुलासा किया गया था माइक ज़ाल्वस्की (CVE-2014-6278) CVE-2014-6271 जितना खराब) शुक्र है कि ज्यादातर लोगों के पास सख्त पैच लगाने का समय था
पार्सर में कीड़े को भी ठीक कर दिया जाएगा, लेकिन वे अब इस मुद्दे का इतना हिस्सा नहीं हैं कि पार्सर अब आसानी से अविश्वसनीय इनपुट के संपर्क में नहीं है।
ध्यान दें कि जब सुरक्षा भेद्यता तय हो गई है, तो संभावना है कि हम उस क्षेत्र में कुछ बदलाव देखेंगे। CVE-2014-6271 के लिए शुरुआती सुधार ने इस मामले में पिछड़ी अनुकूलता को तोड़ दिया है कि वह अपने नाम के साथ .या :उसके साथ काम करना बंद कर देता है /। वे अभी भी बैश द्वारा घोषित किया जा सकता है जो एक असंगत व्यवहार के लिए बनाता है। क्योंकि उनके नाम के साथ .और :उनके कार्यों का आमतौर पर उपयोग किया जाता है, यह संभावना है कि एक पैच पर्यावरण से कम से कम उन लोगों को स्वीकार कर लेगा।
यह पहले क्यों नहीं मिला?
यह भी कुछ ऐसा है जिसके बारे में मैंने सोचा था। मैं कुछ स्पष्टीकरण दे सकता हूं।
सबसे पहले, मुझे लगता है कि यदि कोई सुरक्षा शोधकर्ता (और मैं पेशेवर सुरक्षा शोधकर्ता नहीं हूं) विशेष रूप से बैश में कमजोरियों की तलाश कर रहा था, तो वे संभवतः इसे पा लेंगे।
उदाहरण के लिए, यदि मैं एक सुरक्षा शोधकर्ता होता, तो मेरे दृष्टिकोण निम्न हो सकते हैं:
- देखें कि कहां
bashसे इनपुट मिलता है और इसके साथ क्या होता है। और पर्यावरण एक स्पष्ट है।
- देखें कि
bashदुभाषिया किन स्थानों पर और किस डेटा पर लगाया गया है। फिर, यह बाहर खड़ा होगा।
- निर्यात किए गए फ़ंक्शंस का आयात एक ऐसी सुविधा है
bashजो सेतु / सेटगिड होने पर अक्षम होती है, जो इसे देखने के लिए और भी स्पष्ट स्थान बनाती है।
अब, मुझे संदेह है कि किसी ने भी bash(दुभाषिया) को खतरे के रूप में नहीं माना है, या यह खतरा उस तरह से आ सकता है।
bashदुभाषिया अविश्वस्त इनपुट पर कार्रवाई करने के लिए नहीं होती है।
शेल स्क्रिप्ट (दुभाषिया नहीं) को अक्सर सुरक्षा के दृष्टिकोण से बारीकी से देखा जाता है। शेल सिंटैक्स बहुत अजीब है और विश्वसनीय स्क्रिप्ट लिखने के साथ बहुत सारे कैवेट हैं (कभी-कभी मुझे या दूसरों ने विभाजन + ग्लोब ऑपरेटर का उल्लेख करते हुए या आपको उदाहरण के लिए चर क्यों उद्धृत करना चाहिए?) यह स्क्रिप्ट में सुरक्षा कमजोरियों को खोजने के लिए काफी आम है? अविश्वसनीय डेटा।
इसीलिए आप अक्सर सुनते हैं कि आपको CGI शेल स्क्रिप्ट नहीं लिखनी चाहिए, या अधिकांश स्क्रिप्ट्स पर सेटिड स्क्रिप्ट अक्षम हैं। या जब आपको विश्व -लेखन योग्य निर्देशिकाओं में फ़ाइलों को संसाधित करते समय अतिरिक्त सावधानी बरतनी चाहिए ( उदाहरण के लिए CVE-2011-0441 देखें )।
फोकस उस पर है, शेल स्क्रिप्ट, इंटरप्रेटर नहीं।
आप उपयोगकर्ता द्वारा प्रदान की गई फ़ाइलों के माध्यम से evalया .उस पर कॉल करके या उनके द्वारा कॉल करने के लिए अनल्रेस्ड डेटा (व्याख्या करने के लिए विदेशी डेटा को शेल कोड के रूप में फीड करना) के लिए एक शेल दुभाषिया को उजागर कर सकते हैं , लेकिन फिर आपको bashइसका फायदा उठाने के लिए किसी भेद्यता की आवश्यकता नहीं है। यह बिल्कुल स्पष्ट है कि यदि आप व्याख्या करने के लिए खोल के लिए असमान डेटा पास कर रहे हैं, तो वह इसकी व्याख्या करेगा।
तो शेल को विश्वसनीय संदर्भों में कहा जाता है। इसे व्याख्या करने के लिए निश्चित स्क्रिप्ट दी गई है और अधिक बार नहीं (क्योंकि विश्वसनीय स्क्रिप्ट लिखना बहुत मुश्किल है) प्रक्रिया के लिए निश्चित डेटा।
उदाहरण के लिए, वेब संदर्भ में, शेल को कुछ इस तरह से लागू किया जा सकता है:
popen("sendmail -oi -t", "w");
संभवतः इसके साथ क्या गलत हो सकता है? यदि कुछ गलत की परिकल्पना की गई है, तो यह उस भेजने वाले को खिलाए गए डेटा के बारे में है, न कि उस शेल कमांड लाइन को कैसे पार्स किया जाता है या उस शेल को क्या अतिरिक्त डेटा खिलाया जाता है। ऐसा कोई कारण नहीं है कि आप उस शेल पर जाने वाले पर्यावरण चर पर विचार करना चाहें। और अगर आप ऐसा करेंगे, तो वार्स जिसका नाम शुरुआत के साथ "HTTP_" या अच्छी तरह से जाना जाता है सीजीआई env तरह वार्स यह सब env है एहसास SERVER_PROTOCOLया QUERYSTRINGजिनमें से कोई भी खोल या sendmail किसी भी व्यवसाय के साथ क्या करना है।
विशेषाधिकार उन्नयन संदर्भों में, जैसे कि सेतु / सेटगिड चलाते समय या सूडो के माध्यम से, पर्यावरण को आम तौर पर माना जाता है और अतीत में बहुत सारी कमजोरियां हुई हैं, फिर से शेल के खिलाफ नहीं, लेकिन उन चीजों के खिलाफ जो विशेषाधिकारों को बढ़ाते हैं जैसे sudo(उदाहरण के लिए देखें CVE) -2011-3628 )।
उदाहरण के लिए, bashपर्यावरण पर भरोसा नहीं करता है जब सेटिड या एक सेट्युड कमांड द्वारा बुलाया जाता है ( mountउदाहरण के लिए सोचें जो सहायकों को आमंत्रित करता है)। विशेष रूप से, यह निर्यात कार्यों को अनदेखा करता है।
sudoपर्यावरण को साफ करता है: सब एक सफेद सूची के अलावा डिफ़ॉल्ट रूप से, और यदि नहीं करने के लिए, कम से कम काला सूचियों में कुछ है कि जाना जाता है एक खोल या किसी अन्य (जैसे को प्रभावित करने के लिए कॉन्फ़िगर PS4, BASH_ENV, SHELLOPTS...)। यह उन पर्यावरण चर को भी ब्लैकलिस्ट करता है जिनकी सामग्री के साथ शुरू होता है ()(यही कारण है कि CVE-2014-6271 विशेषाधिकार के माध्यम से विशेषाधिकार बढ़ाने की अनुमति नहीं देता है sudo)।
लेकिन फिर, यह संदर्भों के लिए है जहां पर्यावरण पर भरोसा नहीं किया जा सकता है: किसी भी नाम और मूल्य के साथ कोई भी चर उस संदर्भ में दुर्भावनापूर्ण उपयोगकर्ता द्वारा निर्धारित किया जा सकता है। यह वेब सर्वर / ssh या उन सभी वैक्टर पर लागू नहीं होता है जो CVE-2014-6271 का शोषण करते हैं जहां पर्यावरण नियंत्रित होता है (कम से कम पर्यावरण चर का नाम नियंत्रित होता है ...)
किसी चर को ब्लॉक करना महत्वपूर्ण है echo="() { evil; }", लेकिन ऐसा नहीं है HTTP_FOO="() { evil; }", क्योंकि HTTP_FOOइसे किसी शेल स्क्रिप्ट या कमांड लाइन द्वारा कमांड के रूप में नहीं बुलाया जा सकता है। और अपाचे 2 कभी भी एक echoया BASH_ENVवैरिएबल सेट करने वाला नहीं है ।
यह बिल्कुल स्पष्ट है कि कुछ पर्यावरण चर को उनके नाम के आधार पर कुछ संदर्भों में ब्लैक-लिस्ट किया जाना चाहिए , लेकिन किसी ने भी नहीं सोचा था कि उन्हें उनकी सामग्री (छोड़कर sudo) के आधार पर ब्लैक-लिस्ट किया जाना चाहिए । या दूसरे शब्दों में, किसी ने नहीं सोचा था कि मनमाने ढंग से एनवी वर्जन कोड इंजेक्शन के लिए एक वेक्टर हो सकता है।
जैसे कि व्यापक परीक्षण जब इस सुविधा को जोड़ा गया था तो इसे पकड़ा जा सकता था, मैं कहूंगा कि यह संभावना नहीं है।
जब आप सुविधा के लिए परीक्षण करते हैं , तो आप कार्यक्षमता के लिए परीक्षण करते हैं। कार्यक्षमता ठीक काम करती है। यदि आप फ़ंक्शन को एक bashमंगलाचरण में निर्यात करते हैं , तो यह दूसरे में ठीक से आयात किया जाता है। जब एक ही नाम के साथ एक चर और फ़ंक्शन दोनों का निर्यात किया जाता है या जब यह एक में निर्यात किया गया था से अलग स्थान में आयात किया जाता है, तो बहुत गहन परीक्षण से समस्याएँ देखी जा सकती थीं।
लेकिन भेद्यता का पता लगाने में सक्षम होने के लिए, यह एक कार्यक्षमता परीक्षण नहीं है जो आपको करना होगा। सुरक्षा पहलू पर मुख्य ध्यान केंद्रित करना होगा, और आप कार्यक्षमता का परीक्षण नहीं करेंगे, लेकिन तंत्र और इसका दुरुपयोग कैसे किया जा सकता है।
यह कुछ ऐसा नहीं है कि डेवलपर्स (विशेष रूप से 1989 में) अक्सर उनके दिमाग में होता है, और एक शेल डेवलपर को यह सोचने के लिए बहाना दिया जा सकता है कि उसके सॉफ्टवेयर का नेटवर्क शोषक होने की संभावना नहीं है।