प्रोजेक्ट ज़ीरो ने GitHub पर एक गंभीर सुरक्षा उल्लंघन का विवरण जारी किया और उसकी रिपोर्ट करें बग एक्शन वर्कफ़्लो कमांड को प्रभावित करता है GitHub से और इसे उच्च गंभीरता के रूप में वर्णित किया गया है। (यह बग जुलाई में खोजा गया था, लेकिन, मानक 90-दिवसीय प्रकटीकरण अवधि के अनुसार, विवरण अब केवल सार्वजनिक किया गया है।)
यह दोष उन कुछ कमजोरियों में से एक बन गया जिन्हें ठीक नहीं किया गया था। Google प्रोजेक्ट ज़ीरो द्वारा दी गई मानक 90-दिन की अवधि समाप्त होने से ठीक पहले।
फेलिक्स विल्हेम के अनुसार (जिन्होंने इसे खोजा), प्रोजेक्ट ज़ीरो टीम के सदस्य, दोष GitHub Actions सुविधा को प्रभावित करता है, जो डेवलपर्स के काम को स्वचालित करने का एक उपकरण है। ऐसा इसलिए है क्योंकि एक्शन वर्कफ़्लो कमांड "इंजेक्शन हमलों के प्रति संवेदनशील" हैं:
“एक्शन जीथब एक्शन रनर और निष्पादित एक्शन के बीच संचार चैनल के रूप में वर्कफ़्लो कमांड नामक एक सुविधा का समर्थन करता है। वर्कफ़्लो कमांड runer/src/Runner.Worker/ActionCommandManager.cs में कार्यान्वित किए जाते हैं और दो कमांड फ़्लैग में से एक की तलाश में किए गए सभी कार्यों के STDOUT को पार्स करके काम करते हैं।
इसका उल्लेख करें इस सुविधा के साथ बड़ी समस्या यह है कि यह इंजेक्शन हमलों के प्रति बहुत संवेदनशील है। क्योंकि निष्पादन प्रक्रिया वर्कफ़्लो कमांड के लिए STDOUT पर मुद्रित प्रत्येक पंक्ति को स्कैन करती है, प्रत्येक GitHub क्रिया जिसमें इसके निष्पादन के भाग के रूप में अविश्वसनीय सामग्री शामिल होती है, असुरक्षित होती है।
ज्यादातर मामलों में, मनमाने ढंग से पर्यावरण चर सेट करने की क्षमता के परिणामस्वरूप रिमोट कोड निष्पादन होता है जैसे ही कोई अन्य वर्कफ़्लो निष्पादित होता है। मैंने लोकप्रिय GitHub रिपॉजिटरीज़ को देखने में कुछ समय बिताया है और लगभग कोई भी प्रोजेक्ट जो थोड़ा जटिल GitHub क्रियाओं का उपयोग करता है, इस प्रकार की बग के प्रति संवेदनशील है।
बाद में, कुछ उदाहरण दिए कि कैसे बग का फायदा उठाया जा सकता है और एक समाधान भी सुझाया:
“मैं वास्तव में निश्चित नहीं हूं कि इसे ठीक करने का सबसे अच्छा तरीका क्या है। मुझे लगता है कि वर्कफ़्लो कमांड को लागू करने का तरीका मौलिक रूप से असुरक्षित है। v1 कमांड सिंटैक्स को अस्वीकार करना और एक अनुमति सूची के साथ सेट-एनवी को मजबूत करना संभवतः प्रत्यक्ष आरसीई वैक्टर के खिलाफ काम करेगा।
“हालांकि, बाद के चरणों में उपयोग किए गए 'सामान्य' पर्यावरण चर को ओवरराइड करने की क्षमता भी संभवतः सबसे जटिल कार्यों का फायदा उठाने के लिए पर्याप्त है। मैंने कार्यक्षेत्र में अन्य नियंत्रणों के सुरक्षा प्रभाव पर भी ध्यान नहीं दिया है।
दूसरी ओर, उल्लेख करता है कि यह एक अच्छा दीर्घकालिक समाधान है STDOUT को पार्स करने से बचने के लिए वर्कफ़्लो कमांड को एक अलग पाइपलाइन (उदाहरण के लिए, एक नया फ़ाइल डिस्क्रिप्टर) में ले जाना होगा, लेकिन यह कई मौजूदा एक्शन कोड को तोड़ देगा।
जहां तक GitHub का सवाल है, इसके डेवलपर्स ने 1 अक्टूबर को एक एडवाइजरी पोस्ट की और कमजोर कमांडों की निंदा की, लेकिन तर्क दिया कि विल्हेम ने जो पाया वह वास्तव में "मध्यम सुरक्षा भेद्यता" थी। GitHub ने बग को CVE-2020-15228 के रूप में निर्दिष्ट किया:
“GitHub Actions रनटाइम में एक मध्यम सुरक्षा भेद्यता की पहचान की गई है जो वर्कफ़्लो में पथ और पर्यावरण चर के इंजेक्शन की अनुमति दे सकती है जो STDOUT पर अविश्वसनीय डेटा लॉग करती है। इससे वर्कफ़्लो लेखक के इरादे के बिना पर्यावरण चर पेश किए जा सकते हैं या संशोधित किए जा सकते हैं।
“इस समस्या को हल करने में हमारी मदद करने और आपको पर्यावरण चर को गतिशील रूप से सेट करने की अनुमति देने के लिए, हमने वर्कफ़्लो में पर्यावरण और रूट अपडेट को संभालने के लिए फ़ाइलों का एक नया सेट पेश किया है।
“यदि आप स्व-होस्ट किए गए ब्रोकरों का उपयोग करते हैं, तो सुनिश्चित करें कि वे संस्करण 2.273.1 या उच्चतर पर अपडेट किए गए हैं।
विल्हेम के अनुसार, 12 अक्टूबर को, प्रोजेक्ट ज़ीरो ने GitHub से संपर्क किया और सक्रिय रूप से उन्हें 14 दिनों की पेशकश की, यदि GitHub कमजोर कमांड को अक्षम करने के लिए अधिक समय चाहता था। बेशक, प्रस्ताव स्वीकार कर लिया गया था, और GitHub को 19 अक्टूबर के बाद कमजोर कमांड को अक्षम करने की उम्मीद थी। प्रोजेक्ट ज़ीरो ने फिर 2 नवंबर की नई प्रकटीकरण तिथि निर्धारित की।
Fuente: https://bugs.chromium.org