Glibc कडून ARMv7 साठी memcpy फंक्शनच्या अंमलबजावणीमध्ये गंभीर भेद्यता

सिस्को सुरक्षा संशोधक उघड तपशील असुरक्षा (सीव्हीई- 2020-6096) 32-बिट ARMv7 प्लॅटफॉर्मसाठी Glibc-प्रदान केलेल्या memcpy() फंक्शनच्या अंमलबजावणीमध्ये. कॉपी केलेल्या क्षेत्राचा आकार निर्धारित करणार्‍या पॅरामीटरच्या नकारात्मक मूल्यांच्या चुकीच्या हाताळणीमुळे समस्या उद्भवते, असेंब्ली ऑप्टिमायझेशनच्या वापरामुळे जे स्वाक्षरी केलेल्या 32-बिट पूर्णांकांमध्ये फेरफार करतात. ARMv7 सिस्टीमवर नकारात्मक आकारासह memcpy() कॉल केल्याने मूल्यांची चुकीची तुलना होते आणि निर्दिष्ट बफरच्या सीमेबाहेरील भागात लिहिले जाते.

असुरक्षिततेचा उपयोग अशा परिस्थितीत कोड कार्यान्वित करण्यासाठी केला जाऊ शकतो जेथे आक्रमणकर्ता व्हेरिएबलच्या नकारात्मक मूल्याची निर्मिती आयोजित करू शकतो ज्याद्वारे कॉपी केलेल्या डेटाचा आकार प्रसारित केला जातो (उदाहरणार्थ, 2 GB पेक्षा जास्त हस्तांतरित करताना ते नकारात्मक होईल. डेटा, परंतु हल्ल्यादरम्यान, बफर मर्यादेच्या पलीकडे जाण्यासाठी, आपल्याला किमान 4GB हस्तांतरित करणे आवश्यक आहे). memcpy() फंक्शन ऍप्लिकेशन्समध्ये मोठ्या प्रमाणावर वापरले जाते आणि ARMv7 प्रोसेसर ऑटोमोटिव्ह सिस्टम, मोबाइल, इंडस्ट्रियल, कंझ्युमर, कम्युनिकेशन्स आणि एम्बेडेड डिव्हाइसेसमध्ये सामान्य आहेत, जे ब्लूटूथ, HD रेडिओ/डीएबी, यूएसबी, कॅन बस, वापरून हल्ले होऊ शकतात. वाय-फाय फाय आणि इतर बाह्य डेटा स्रोत (उदाहरणार्थ, आकाराच्या निर्बंधांशिवाय इनपुट डेटा स्वीकारणाऱ्या नेटवर्कवर प्रवेश करण्यायोग्य सेवा आणि अनुप्रयोगांवर हल्ला केला जाऊ शकतो).

ऑटोमोबाईल वाय-फाय नेटवर्कद्वारे प्रवेश करण्यायोग्य ऑटोमोबाईल माहिती प्रणालीमध्ये तयार केलेल्या HTTP सर्व्हरवर हल्ला करण्यासाठी कार्यरत शोषणाची निर्मिती हे एक उदाहरण आहे. बाहेरील हल्लेखोर खूप मोठी GET विनंती पाठवून या सर्व्हरवरील memcpy असुरक्षिततेचा फायदा घेऊ शकतो आणि सिस्टममध्ये रूट प्रवेश मिळवू शकतो.

32-बिट x86 सिस्टीमवर, समस्या दिसून येत नाही, कारण या आर्किटेक्चरसाठी memcpy अंमलबजावणी आकार व्हेरिएबलला आकार_t (असेंबली भाषेत) च्या स्वाक्षरी नसलेल्या पूर्णांक मूल्याच्या रूपात योग्यरित्या समजते. अंमलबजावणी ARMv7 साठी ते size_t ऐवजी स्वाक्षरी पूर्णांक म्हणून मानले जाते). निराकरण सध्या उपलब्ध आहे पॅच, जे ऑगस्ट Glibc 2.32 अपडेटमध्ये समाविष्ट केले जाईल.
स्वाक्षरी केलेल्या ऑपरेंड्स (bge आणि blt) वर कार्य करणाऱ्या असेंब्ली निर्देशांचा वापर अ-स्वाक्षरीत प्रतिरूप (blo आणि bhs) सह पुनर्स्थित करण्यासाठी निराकरण उकळते.

अद्यापही समस्या सुटलेली नाही डेबियन 9 आणि 10 (डेबियन 8 मध्ये दृश्यमान नाही), Fedora, उबंटू, OpenEmbedded, Tizen (glibc द्वारे वापरलेले). रहेल и SUSE समस्या प्रभावित होत नाही कारण ते 32-बिट ARMv7 सिस्टमला समर्थन देत नाहीत. Android ला असुरक्षिततेचा परिणाम होत नाही कारण ते स्वतःचे libc (Bionic) अंमलबजावणी वापरते. IN ओपन डब्लूआरटी डीफॉल्टनुसार, बहुतेक बिल्ड्स Musl वापरतात, परंतु glibc देखील रेपॉजिटरीमध्ये उपलब्ध आहे.

स्त्रोत: opennet.ru