प्रोजेक्ट झिरोने गिटहबवर गंभीर सुरक्षा भंग केल्याचा तपशील प्रसिद्ध केला आणि ते त्या नोंदवतात त्रुटी कृती कार्यप्रवाह आदेशांवर परिणाम करते गिटहब कडून आणि उच्च तीव्रतेचे वर्णन केले आहे. (हा बग जुलैमध्ये सापडला होता, परंतु प्रमाण 90-दिवसांच्या प्रकटीकरण कालावधीत, तपशील फक्त आता जाहीर केला गेला आहे.)
हा दोष निराकरण न झालेल्या काही असुरक्षांपैकी एक बनला गूगल प्रोजेक्ट झिरोने मंजूर केलेल्या मानक 90-दिवसांच्या टाइमफ्रेमच्या योग्यरित्या कालबाह्य झाले.
फेलिक्स विल्हेल्मच्या मते प्रोजेक्ट झिरो टीमचा सदस्य (याचा शोध कोणी घेतला) विकासकांचे कार्य स्वयंचलित करण्याचे साधन गिटहबच्या कृती कार्यावर दोष निर्माण करतो. कारण अ‍ॅक्शन वर्कफ्लो आदेश "इंजेक्शन हल्ल्यांसाठी असुरक्षित" आहेत:
“Gक्शन गीथब broक्शन ब्रोकर आणि एक्जिक्युटेड actionक्शन दरम्यान संवाद चॅनेल म्हणून वर्कफ्लो कमांड नावाच्या वैशिष्ट्यास समर्थन देते. वर्कफ्लो आदेश / एसआरसी / रनर मध्ये लागू केले आहेत. वर्कर / mandक्शन कॉमांडमॅनेजर. सी आणि ते दोन कमांडर मार्करपैकी एक शोधून केलेल्या सर्व क्रियांच्या एसटीडीओटीचे विश्लेषण करून कार्य करते.
त्याचा उल्लेख करा या वैशिष्ट्यासह मोठी समस्या म्हणजे ती इंजेक्शनच्या हल्ल्यात असुरक्षित असते. वर्कफ्लो आदेशांकरिता एसटीडीओयूटीमध्ये छापलेल्या प्रत्येक पंक्तीची अंमलबजावणी प्रक्रिया स्कॅन केल्यामुळे, अंमलबजावणीचा एक भाग म्हणून अविश्वासू सामग्री असलेली प्रत्येक जीटहब क्रिया असुरक्षित आहे.
बर्‍याच प्रकरणांमध्ये, अनियंत्रित वातावरणीय चल सेट करण्याची क्षमता दुसर्या वर्कफ्लोच्या कार्यवाही होताच रिमोट कोड अंमलात आणते. मी लोकप्रिय गिटहब रेपॉजिटरीज आणि थोडासा जटिल गिटहब क्रिया वापरणारा कोणताही प्रकल्प या प्रकारच्या बगसाठी असुरक्षित आहे हे शोधण्यात थोडा वेळ घालवला आहे.
नंतर बगचा कसा वापर केला जाऊ शकतो याची काही उदाहरणे दिली आणि एक उपाय सुचविला:
“निराकरण करण्याचा उत्तम मार्ग कोणता आहे याबद्दल मला खरोखर खात्री नाही. मला असे वाटते की वर्कफ्लो आदेश ज्या प्रकारे लागू केले गेले आहेत ते मूलभूतपणे असुरक्षित आहेत. परवानगी यादीसह v1 कमांड सिंटॅक्स आणि स्ट्रेंइन्जेट-एनव्हीचा अवमूल्यन करणे कदाचित थेट आरसीई वेक्टर विरूद्ध कार्य करेल.
“तथापि, नंतरच्या चरणांमध्ये वापरल्या जाणार्‍या 'सामान्य' वातावरणीय चरांना अधिलिखित करण्याची क्षमता कदाचित अधिक जटिल क्रियांच्या शोषणासाठी पुरेसे आहे. किंवा मी कार्यक्षेत्रातील इतर नियंत्रणाच्या सुरक्षिततेच्या प्रभावाचे विश्लेषण केले नाही.
दुसरीकडे, उल्लेख की एक चांगला दीर्घकालीन समाधान एसटीडीओयूटीद्वारे विश्लेषित करणे टाळण्यासाठी वर्कफ्लो आदेश स्वतंत्र चॅनेलवर (उदा. नवीन फाइल वर्णनकर्ता) हलविणे हे आहे, परंतु यामुळे बर्‍याच अस्तित्वातील अ‍ॅक्शन कोड खंडित होईल.
गिटहबबद्दल सांगायचे तर, त्याच्या विकसकांनी 1 ऑक्टोबरला एक सल्लागार पोस्ट केला आणि असुरक्षित आदेशांची नाकारली, परंतु असा युक्तिवाद केला की विल्हेल्मला जे सापडले ते वस्तुतः "मध्यम सुरक्षा असुरक्षा" आहे. गिटहबने बग अभिज्ञापक सीव्हीई -2020-15228 नियुक्त केले:
“गीटहब runक्शन रनटाइममध्ये एक मध्यम सुरक्षा असुरक्षितता ओळखली गेली आहे जी पथ आणि वातावरणीय चलच्या इंजेक्शनला वर्कफ्लोमध्ये अनुमती देऊ शकते जे एसटीडीओटीवर अविश्वासू डेटा लॉग करते. यामुळे वर्कफ्लो लेखकाच्या हेतूशिवाय पर्यावरणीय चलांची ओळख किंवा सुधारणा होऊ शकते.
“आम्हाला या समस्येचे निराकरण करण्यात आणि वातावरणीय चल बदलण्यास गतिकरित्या परवानगी देण्यास मदत करण्यासाठी आम्ही कार्यप्रवाहात पर्यावरण आणि पथ अद्ययावत हाताळण्यासाठी फायलींचा एक नवीन संच सादर केला आहे.
“आपण सेल्फ-होस्ट केलेले ब्रोकर वापरत असल्यास, ते आवृत्ती २.२2.273.1.१ किंवा त्याहून अधिक आवृत्तीमध्ये अद्ययावत असल्याची खात्री करा.
विल्हेल्मच्या म्हणण्यानुसार, 12 ऑक्टोबर रोजी प्रोजेक्ट झिरोने गिटहबशी संपर्क साधला आणि गिटहबला असुरक्षित आदेश अक्षम करण्यासाठी अधिक वेळ हवा असेल तर त्यांनी त्यांना 14 दिवसांची मुदत दिली. अर्थात, ही ऑफर मान्य झाली आणि गीटहब 19 ऑक्टोबरनंतर असुरक्षित कमांड अक्षम करण्याची अपेक्षा करीत होते. त्यानंतर प्रोजेक्ट झिरोने 2 नोव्हेंबर रोजी नवीन प्रकटीकरण तारीख निश्चित केली.
स्त्रोत: https://bugs.chromium.org