ट्रोजन सोर्स अटैक कोड में ऐसे बदलाव लाने के लिए है जो डेवलपर के लिए अदृश्य हैं

कैम्ब्रिज विश्वविद्यालय के शोधकर्ताओं ने सहकर्मी-समीक्षित स्रोत कोड में चुपचाप दुर्भावनापूर्ण कोड डालने की एक तकनीक प्रकाशित की है। तैयार आक्रमण विधि (सीवीई-2021-42574) को ट्रोजन सोर्स नाम के तहत प्रस्तुत किया गया है और यह पाठ के निर्माण पर आधारित है जो संकलक/दुभाषिया और कोड देखने वाले व्यक्ति के लिए अलग दिखता है। विधि के उदाहरण सी, सी++ (जीसीसी और क्लैंग), सी#, जावास्क्रिप्ट (नोड.जेएस), जावा (ओपनजेडीके 16), रस्ट, गो और पायथन के लिए आपूर्ति किए गए विभिन्न कंपाइलरों और दुभाषियों के लिए प्रदर्शित किए गए हैं।

यह विधि कोड टिप्पणियों में विशेष यूनिकोड वर्णों के उपयोग पर आधारित है जो द्विदिश पाठ के प्रदर्शन क्रम को बदल देती है। ऐसे नियंत्रण वर्णों की सहायता से, पाठ के कुछ हिस्सों को बाएँ से दाएँ प्रदर्शित किया जा सकता है, जबकि अन्य - दाएँ से बाएँ। रोजमर्रा के व्यवहार में, ऐसे नियंत्रण वर्णों का उपयोग किया जा सकता है, उदाहरण के लिए, किसी फ़ाइल में हिब्रू या अरबी में कोड लाइनें डालने के लिए। लेकिन यदि आप निर्दिष्ट वर्णों का उपयोग करके विभिन्न पाठ दिशाओं वाली पंक्तियों को एक पंक्ति में जोड़ते हैं, तो दाएं से बाएं प्रदर्शित पाठ के अंश बाएं से दाएं प्रदर्शित मौजूदा नियमित पाठ को ओवरलैप कर सकते हैं।

इस पद्धति का उपयोग करके, आप कोड में एक दुर्भावनापूर्ण निर्माण जोड़ सकते हैं, लेकिन फिर निम्नलिखित टिप्पणी में या दाएं से बाएं दिखाए गए शाब्दिक वर्णों को जोड़कर, कोड को देखते समय इस निर्माण के साथ पाठ को अदृश्य बना दें, जो पूरी तरह से खराब हो जाएगा दुर्भावनापूर्ण प्रविष्टि पर अलग-अलग अक्षर आरोपित किए जा रहे हैं। ऐसा कोड शब्दार्थ की दृष्टि से सही रहेगा, लेकिन उसकी व्याख्या और प्रदर्शन अलग ढंग से किया जाएगा।

कोड की समीक्षा करते समय, एक डेवलपर को वर्णों के दृश्य क्रम का सामना करना पड़ेगा और वह आधुनिक टेक्स्ट एडिटर, वेब इंटरफ़ेस या आईडीई में एक गैर-संदिग्ध टिप्पणी देखेगा, लेकिन कंपाइलर और दुभाषिया वर्णों के तार्किक क्रम का उपयोग करेंगे और करेंगे टिप्पणियों में द्विदिश पाठ पर ध्यान दिए बिना, दुर्भावनापूर्ण प्रविष्टि को वैसे ही संसाधित करें। समस्या विभिन्न लोकप्रिय कोड संपादकों (वीएस कोड, एमएसीएस, एटम) के साथ-साथ रिपॉजिटरी (गिटहब, गिटलैब, बिटबकेट और सभी एटलसियन उत्पादों) में कोड देखने के इंटरफेस को प्रभावित करती है।

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

उदाहरण के लिए, एक हमलावर एक बदलाव का प्रस्ताव कर सकता है जिसमें यह पंक्ति शामिल है: if access_level != "user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}" {

जो समीक्षा इंटरफ़ेस में प्रदर्शित किया जाएगा जैसे कि access_level != "user" {// जांचें कि क्या admin

इसके अतिरिक्त, एक और आक्रमण संस्करण प्रस्तावित किया गया है (सीवीई-2021-42694), जो होमोग्लिफ्स के उपयोग से जुड़ा है, ऐसे वर्ण जो दिखने में समान हैं, लेकिन अर्थ में भिन्न हैं और अलग-अलग यूनिकोड कोड हैं (उदाहरण के लिए, वर्ण "ɑ" जैसा दिखता है) ए", "ɡ" - "जी", "ɩ" - "एल")। डेवलपर्स को गुमराह करने के लिए कुछ भाषाओं में फ़ंक्शंस और वेरिएबल्स के नाम पर समान वर्णों का उपयोग किया जा सकता है। उदाहरण के लिए, अविभाज्य नामों वाले दो कार्यों को परिभाषित किया जा सकता है जो अलग-अलग क्रियाएं करते हैं। विस्तृत विश्लेषण के बिना, यह तुरंत स्पष्ट नहीं है कि इन दोनों कार्यों में से कौन सा फ़ंक्शन किसी विशिष्ट स्थान पर कहा जाता है।

एक सुरक्षा उपाय के रूप में, यह अनुशंसा की जाती है कि यूनिकोड वर्णों का समर्थन करने वाले कंपाइलर, दुभाषिए और असेंबली उपकरण एक त्रुटि या चेतावनी प्रदर्शित करें यदि टिप्पणियों, स्ट्रिंग शाब्दिक, या पहचानकर्ताओं में अयुग्मित नियंत्रण वर्ण हैं जो आउटपुट की दिशा बदलते हैं (यू+202ए, U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E और U+200F)। ऐसे वर्णों को प्रोग्रामिंग भाषा विशिष्टताओं में भी स्पष्ट रूप से प्रतिबंधित किया जाना चाहिए और कोड संपादकों और रिपॉजिटरी इंटरफेस में उनका सम्मान किया जाना चाहिए।

परिशिष्ट 1: जीसीसी, एलएलवीएम/क्लैंग, रस्ट, गो, पायथन और बिनुटिल्स के लिए भेद्यता पैच तैयार किए गए हैं। गिटहब, बिटबकेट और जीरा ने भी समस्या का समाधान किया। GitLab का समाधान प्रगति पर है. समस्याग्रस्त कोड की पहचान करने के लिए, कमांड का उपयोग करने का सुझाव दिया गया है: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/ स्रोत

परिशिष्ट 2: प्लान 9 ओएस और गो प्रोग्रामिंग भाषा के डेवलपर्स में से एक, रस कॉक्स ने वर्णित हमले विधि पर अत्यधिक ध्यान देने की आलोचना की, जो लंबे समय से ज्ञात है (गो, रस्ट, सी++, रूबी) और इसे गंभीरता से नहीं लिया गया था . कॉक्स के अनुसार, समस्या मुख्य रूप से कोड संपादकों और वेब इंटरफेस में जानकारी के सही प्रदर्शन से संबंधित है, जिसे समीक्षा के दौरान सही टूल और कोड विश्लेषक का उपयोग करके हल किया जा सकता है। इसलिए, सट्टा हमलों पर ध्यान आकर्षित करने के बजाय, कोड और निर्भरता समीक्षा प्रक्रियाओं में सुधार पर ध्यान केंद्रित करना अधिक उचित होगा।

रास कॉक्स का यह भी मानना ​​है कि कंपाइलर समस्या को ठीक करने के लिए सही जगह नहीं है, क्योंकि कंपाइलर स्तर पर खतरनाक प्रतीकों पर प्रतिबंध लगाने से, उपकरणों की एक बड़ी परत बनी रहती है जिसमें इन प्रतीकों का उपयोग स्वीकार्य रहता है, जैसे बिल्ड सिस्टम, असेंबलर, पैकेज प्रबंधक और विभिन्न कॉन्फ़िगरेशन पार्सर और डेटा। उदाहरण के तौर पर, रस्ट प्रोजेक्ट दिया गया है, जिसने कंपाइलर में एलटीआर/आरटीएल कोड की प्रोसेसिंग पर रोक लगा दी, लेकिन कार्गो पैकेज मैनेजर में एक फिक्स नहीं जोड़ा, जो कार्गो.टॉएमएल फ़ाइल के माध्यम से एक समान हमले की अनुमति देता है। इसी तरह, BUILD.bazen, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml और require.txt जैसी फ़ाइलें हमलों के स्रोत बन सकती हैं।

स्रोत: opennet.ru