विकासकाला अदृश्य असलेल्या कोडमध्ये बदल सादर करण्यासाठी ट्रोजन स्त्रोत हल्ला

केंब्रिज विद्यापीठातील संशोधकांनी पीअर-रिव्ह्यू केलेल्या स्त्रोत कोडमध्ये दुर्भावनायुक्त कोड शांतपणे घालण्याचे तंत्र प्रकाशित केले आहे. तयार केलेली हल्ला पद्धत (CVE-2021-42574) ट्रोजन सोर्स या नावाने सादर केली आहे आणि ती संकलक/दुभाषी आणि कोड पाहणाऱ्या व्यक्तीसाठी भिन्न दिसणार्‍या मजकुराच्या निर्मितीवर आधारित आहे. पद्धतीची उदाहरणे C, C++ (gcc आणि clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go आणि Python साठी पुरवलेल्या विविध कंपायलर आणि इंटरप्रिटरसाठी दाखवली जातात.

ही पद्धत कोड टिप्पण्यांमध्ये विशेष युनिकोड वर्णांच्या वापरावर आधारित आहे जी द्विदिशात्मक मजकूराचा प्रदर्शन क्रम बदलतात. अशा नियंत्रण वर्णांच्या मदतीने, मजकूराचे काही भाग डावीकडून उजवीकडे प्रदर्शित केले जाऊ शकतात, तर काही - उजवीकडून डावीकडे. दैनंदिन व्यवहारात, अशा नियंत्रण वर्णांचा वापर केला जाऊ शकतो, उदाहरणार्थ, फाइलमध्ये हिब्रू किंवा अरबीमध्ये कोड ओळी घालण्यासाठी. परंतु तुम्ही एका ओळीत वेगवेगळ्या मजकूर दिशानिर्देशांसह ओळी एकत्र केल्यास, निर्दिष्ट वर्ण वापरून, उजवीकडून डावीकडे प्रदर्शित मजकूराचे परिच्छेद डावीकडून उजवीकडे प्रदर्शित विद्यमान नियमित मजकूर ओव्हरलॅप करू शकतात.

या पद्धतीचा वापर करून, तुम्ही कोडमध्ये एक दुर्भावनापूर्ण रचना जोडू शकता, परंतु नंतर कोड पाहताना, खालील टिप्पणीमध्ये किंवा उजवीकडून डावीकडे दर्शविलेले शाब्दिक वर्ण जोडून या रचनासह मजकूर अदृश्य करा, ज्यामुळे पूर्णपणे भिन्न वर्ण दुर्भावनायुक्त अंतर्भूत करण्यावर अधिरोपित केले जात आहेत. असा कोड शब्दार्थाने बरोबर राहील, परंतु त्याचा अर्थ लावला जाईल आणि वेगळ्या प्रकारे प्रदर्शित केला जाईल.

कोडचे पुनरावलोकन करताना, विकसकाला वर्णांच्या व्हिज्युअल ऑर्डरचा सामना करावा लागेल आणि त्याला आधुनिक मजकूर संपादक, वेब इंटरफेस किंवा IDE मध्ये एक गैर-संशयास्पद टिप्पणी दिसेल, परंतु कंपायलर आणि इंटरप्रिटर वर्णांच्या तार्किक क्रमाचा वापर करतील. टिप्पण्यांमधील द्विदिशात्मक मजकुराकडे लक्ष न देता, दुर्भावनापूर्ण अंतर्भूततेवर प्रक्रिया करा. समस्या विविध लोकप्रिय कोड एडिटर (VS कोड, Emacs, Atom), तसेच रेपॉजिटरीजमधील कोड पाहण्यासाठी इंटरफेस (GitHub, Gitlab, BitBucket आणि सर्व Atlassian उत्पादने) प्रभावित करते.

दुर्भावनापूर्ण कृती अंमलात आणण्यासाठी पद्धत वापरण्याचे अनेक मार्ग आहेत: लपविलेले "रिटर्न" अभिव्यक्ती जोडणे, ज्यामुळे कार्य वेळेपूर्वी पूर्ण होते; सामान्यपणे वैध रचना म्हणून दृश्यमान असणार्‍या अभिव्यक्तींवर टिप्पणी करणे (उदाहरणार्थ, महत्त्वाच्या तपासण्या अक्षम करण्यासाठी); इतर स्ट्रिंग मूल्ये नियुक्त करणे ज्यामुळे स्ट्रिंग प्रमाणीकरण अयशस्वी होते.

उदाहरणार्थ, आक्रमणकर्ता बदल सुचवू शकतो ज्यामध्ये ओळ समाविष्ट आहे: if access_level != "वापरकर्ता{U+202E} {U+2066}// प्रशासक{U+2069} {U+2066}" {

जे रिव्ह्यू इंटरफेसमध्ये जसे access_level != “वापरकर्ता” { // प्रशासक आहे का ते तपासा

या व्यतिरिक्त, आणखी एक आक्रमण प्रकार प्रस्तावित केला गेला आहे (CVE-2021-42694), समरूपतेच्या वापराशी संबंधित, वर्ण जे दिसायला सारखे आहेत, परंतु अर्थाने भिन्न आहेत आणि भिन्न युनिकोड कोड आहेत (उदाहरणार्थ, वर्ण “ɑ” सारखा दिसतो. a", "ɡ" - "g", "ɩ" - "l"). विकासकांची दिशाभूल करण्यासाठी काही भाषांमध्ये फंक्शन्स आणि व्हेरिएबल्सच्या नावावर तत्सम अक्षरे वापरली जाऊ शकतात. उदाहरणार्थ, अभेद्य नावांसह दोन कार्ये परिभाषित केली जाऊ शकतात जी भिन्न क्रिया करतात. तपशीलवार विश्लेषणाशिवाय, या दोन फंक्शन्सपैकी कोणत्या विशिष्ट ठिकाणी म्हणतात हे त्वरित स्पष्ट होत नाही.

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

परिशिष्ट 1: GCC, LLVM/Clang, Rust, Go, Python आणि binutils साठी असुरक्षितता पॅच तयार केले आहेत. GitHub, Bitbucket आणि Jira ने देखील समस्येचे निराकरण केले. GitLab साठी निराकरण प्रगतीपथावर आहे. समस्याप्रधान कोड ओळखण्यासाठी, कमांड वापरण्याची शिफारस केली जाते: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069/' स्रोत

परिशिष्ट 2: Russ Cox, प्लॅन 9 OS आणि Go प्रोग्रामिंग भाषेच्या विकासकांपैकी एक, वर्णन केलेल्या आक्रमण पद्धतीकडे जास्त लक्ष दिल्याबद्दल टीका केली, जी बर्याच काळापासून ज्ञात आहे (Go, Rust, C++, Ruby) आणि गांभीर्याने घेतले गेले नाही. . कॉक्सच्या मते, समस्या मुख्यतः कोड एडिटर आणि वेब इंटरफेसमधील माहितीच्या योग्य प्रदर्शनाशी संबंधित आहे, जी पुनरावलोकनादरम्यान योग्य साधने आणि कोड विश्लेषक वापरून सोडवली जाऊ शकते. त्यामुळे, सट्टा हल्ल्यांकडे लक्ष वेधण्याऐवजी, कोड आणि अवलंबित्व पुनरावलोकन प्रक्रिया सुधारण्यावर लक्ष केंद्रित करणे अधिक योग्य ठरेल.

रास कॉक्सचा असाही विश्वास आहे की समस्या सोडवण्यासाठी कंपायलर हे योग्य ठिकाण नाही, कारण कंपायलर स्तरावर धोकादायक चिन्हांवर बंदी घातल्याने, या चिन्हांचा वापर स्वीकार्य राहते, जसे की बिल्ड सिस्टम, असेंबलर, पॅकेज व्यवस्थापक आणि विविध कॉन्फिगरेशन विश्लेषक आणि डेटा. उदाहरण म्हणून, रस्ट प्रोजेक्ट दिलेला आहे, ज्याने कंपाइलरमध्ये LTR/RTL कोडची प्रक्रिया प्रतिबंधित केली आहे, परंतु कार्गो पॅकेज मॅनेजरमध्ये निराकरण जोडले नाही, जे Cargo.toml फाइलद्वारे समान आक्रमणास अनुमती देते. त्याचप्रमाणे, BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml आणि requirements.txt सारख्या फायली हल्ल्यांचे स्रोत बनू शकतात.

स्त्रोत: opennet.ru