शोषण केल्यास, या त्रुटी हल्लेखोरांना संवेदनशील माहितीवर अनधिकृत प्रवेश मिळवू शकतात किंवा सामान्यत: समस्या निर्माण करू शकतात
एक असुरक्षितता ओळखली गेली आहे (CVE-2022-37454 अंतर्गत आधीच सूचीबद्ध) en क्रिप्टोग्राफिक हॅश फंक्शनची अंमलबजावणी SHA-3 (केकॅक), XKCP पॅकेज (विस्तारित केकॅक कोड पॅकेज) मध्ये ऑफर केले जाते.
ओळखले संवेदनशीलता बफर ओव्हरफ्लो होऊ शकते तयार डेटा प्रक्रिया दरम्यान. ही समस्या SHA-3 च्या विशिष्ट अंमलबजावणीच्या कोडमधील बगमुळे आहे, अल्गोरिदममध्येच भेद्यतेमुळे नाही.
पॅकेज XKCP केकॅक डेव्हलपमेंट टीमच्या मदतीने विकसित केलेले SHA-3 ची अधिकृत अंमलबजावणी म्हणून ओळखले जाते आणि SHA-3 सह कार्य करण्यासाठी फंक्शन्सचा आधार म्हणून वापरला जातो विविध प्रोग्रामिंग भाषांमध्ये (उदाहरणार्थ, XKCP कोड Python hashlib मॉड्यूल, Ruby digest-sha3 पॅकेज आणि PHP हॅश_* फंक्शन्समध्ये वापरला जातो).
समस्या ओळखणाऱ्या संशोधकाच्या मते, क्रिप्टोग्राफिक गुणधर्मांचे उल्लंघन करण्यासाठी भेद्यता वापरू शकते हॅश फंक्शनचे आणि प्रथम आणि द्वितीय प्रीइमेज शोधा, तसेच टक्कर निर्धारित करा.
सेगमेंटेशन फॉल्टचे कारण असे आहे की स्क्रिप्ट्स बफरमध्ये धारण करण्यापेक्षा जास्त डेटा लिहिण्याचा प्रयत्न करतात. अशा भेद्यतेला बफर ओव्हरफ्लो म्हणून ओळखले जाते, ज्याचे वर्णन OWASP "कदाचित सॉफ्टवेअर सुरक्षा भेद्यतेचे सर्वात प्रसिद्ध स्वरूप" म्हणून करते.
कोडचा एक छोटा प्रकार अनंत लूपला कारणीभूत ठरेल: फक्त 4294967295 ला 4294967296 ने बदला. CVE-2019-8741 ची समानता लक्षात घ्या, आणखी एक भेद्यता मला आढळली ज्याने 1.400 अब्ज Apple उपकरणांच्या फर्मवेअरवर परिणाम केला, ज्यामुळे लूप अनंत देखील झाला.
तसेच, प्रोटोटाइप शोषणाच्या निर्मितीची घोषणा केली आहे, que हॅशची गणना करताना कोडची अंमलबजावणी करण्यास अनुमती देते विशेषतः डिझाइन केलेल्या फाइलमधून. SHA-3 (उदाहरणार्थ, Ed448) वापरून डिजिटल स्वाक्षरी पडताळणी अल्गोरिदमवर हल्ला करण्यासाठी असुरक्षा देखील वापरली जाऊ शकते. असुरक्षा सामान्यपणे काढून टाकल्यानंतर, हल्ल्याच्या पद्धतींचे तपशील नंतरच्या तारखेला प्रसिद्ध केले जाणे अपेक्षित आहे.
पायथन आणि पीएचपी सारख्या "सुरक्षित" भाषांमध्ये अशा प्रकारचे वर्तन घडू नये, कारण ते सर्व वाचन आणि लेखन ऑपरेशन्स बफरच्या मर्यादेत आहेत हे तपासतात. तथापि, समस्या अशी आहे की असुरक्षितता अंतर्निहित "असुरक्षित" सी भाषेत आहे...
अद्याप असुरक्षिततेचा व्यवहारात विद्यमान अनुप्रयोगांवर कसा परिणाम होतो हे स्पष्ट नाही, कोडमध्ये समस्या प्रकट होण्यासाठी, ब्लॉक्सवरील चक्रीय हॅश गणना वापरली जाणे आवश्यक आहे आणि प्रक्रिया केलेल्या ब्लॉकपैकी एकाचा आकार सुमारे 4 GB (किमान 2^32 - 200 बाइट्स) असणे आवश्यक आहे.
इनपुट डेटावर एकाच वेळी प्रक्रिया करताना (भागांद्वारे हॅशची अनुक्रमिक गणना न करता), समस्या दिसून येत नाही. एक सोपी संरक्षण पद्धत म्हणून, हॅश गणनाच्या एका पुनरावृत्तीमध्ये समाविष्ट असलेल्या डेटाचा कमाल आकार मर्यादित करण्याचा प्रस्ताव आहे.
असुरक्षित कोड जानेवारी 2011 मध्ये प्रकाशित झाला होता, त्यामुळे ही असुरक्षा शोधण्यासाठी एका दशकापेक्षा जास्त वेळ लागला. क्रिप्टोग्राफिक अंमलबजावणीमध्ये भेद्यता शोधणे कठीण आहे असे दिसते, जरी ते सिस्टमच्या एकूण सुरक्षिततेमध्ये महत्त्वपूर्ण भूमिका बजावतात. (कदाचित लोक अशा असुरक्षा शोधत नसतील, कारण XKCP मधील ही भेद्यता किंवा वर नमूद केलेली Apple असुरक्षा कोणत्याही बग बाउंटी प्रोग्रामसाठी पात्र नाहीत!)
असुरक्षितता इनपुट डेटाच्या ब्लॉक प्रोसेसिंगमधील त्रुटीमुळे आहे. "इंट" प्रकारासह मूल्यांची चुकीची तुलना केल्यामुळे, थकबाकी डेटाचा चुकीचा आकार निर्धारित केला जातो, ज्यामुळे वाटप केलेल्या बफरच्या बाहेर रांग लिहिली जाते.
विशेषतः, हे नमूद केले आहे की तुलना करताना, अभिव्यक्ती «partialBlock + instance->byteIOIndex«, जे, घटक भागांच्या मोठ्या मूल्यांसह, पूर्णांक ओव्हरफ्लोकडे नेले. तसेच, कोडमध्ये चुकीचे टाइपकास्ट "(असाइन केलेले int)(dataByteLen - i)" होते, ज्यामुळे 64-बिट आकार_टी प्रकार असलेल्या सिस्टमवर ओव्हरफ्लो झाला.
शेवटी आपल्याला त्याबद्दल अधिक जाणून घेण्यात स्वारस्य असल्यास, आपण मधील तपशील तपासू शकता खालील दुवा.