Stack Canaries
स्टैकगार्ड और स्टैकशील्ड
स्टैकगार्ड एक विशेष मान जिसे कैनेरी के रूप में जाना जाता है, EIP (विस्तारित निर्देशिका पॉइंटर) से पहले डालता है, विशेष रूप से 0x000aff0d (नल, न्यूलाइन, ईओएफ, कैरिज रिटर्न को प्रतिनिधित्व करता है) ताकि बफर ओवरफ्लो के खिलाफ सुरक्षा प्रदान कर सके। हालांकि, recv(), memcpy(), read(), और bcopy() जैसी फ़ंक्शन अब भी संक्रमित हैं, और यह EBP (बेस पॉइंटर) की सुरक्षा नहीं करता है।
स्टैकशील्ड स्टैकगार्ड से एक अधिक विवेकपूर्ण दृष्टिकोण अपनाता है जिसमें एक ग्लोबल रिटर्न स्टैक बनाया गया है, जो सभी रिटर्न पतों (EIPs) को संग्रहित करता है। यह सेटअप सुनिश्चित करता है कि कोई भी ओवरफ्लो हानि नहीं पहुंचाता है, क्योंकि यह संग्रहित और वास्तविक रिटर्न पतों के बीच तुलना करने की अनुमति देता है ताकि ओवरफ्लो घटनाएं पता लगाई जा सकें। इसके अतिरिक्त, स्टैकशील्ड स्टैक कैनेरी को लेकर एक सीमा मान के खिलाफ रिटर्न पत की जांच कर सकता है ताकि पता लगा सके कि EIP अपेक्षित डेटा स्थान के बाहर निशानित करता है। हालांकि, यह सुरक्षा तकनीक Return-to-libc, ROP (Return-Oriented Programming), या ret2ret जैसी तकनीकों के माध्यम से टाला जा सकता है, इसका मतलब है कि स्टैकशील्ड भी स्थानीय चरों की सुरक्षा नहीं करता।
स्टैक स्मैश प्रोटेक्टर (ProPolice) -fstack-protector:
-fstack-protector:यह तंत्र EBP से पहले एक कैनेरी डालता है, और स्थानीय चरों को पुनर्व्यवस्थित करके बफर्स को उच्च मेमोरी पतों पर स्थानित करता है, जिससे वे अन्य चरों को अधिग्रहण न करें। यह सुरक्षित रूप से उच्च स्थानीय चरों पर पारित तार्किक और इसके प्रतियोगियों के रूप में उपयोग करने के लिए उनकी प्रतियां की नकल करता है। हालांकि, यह कम से कम 8 तत्वों वाले एरे या उपयोगकर्ता की संरचना में बफर्स की सुरक्षा नहीं करता है।
कैनेरी एक यादृच्छिक संख्या है जो /dev/urandom से उत्पन्न होती है या एक डिफ़ॉल्ट मान 0xff0a0000 होता है। यह TLS (सूत्र स्थानीय संग्रहण) में संग्रहित होता है, जो धागे के स्थानों के बीच साझा मेमोरी स्थानों को धागा-विशेषित ग्लोबल या स्थायी चरों के रूप में रखने की अनुमति देता है। ये चर पहले मूल प्रक्रिया से कॉपी किए जाते हैं, और बच्चे प्रक्रियाएँ अपने डेटा को परिवर्तित कर सकते हैं बिना माता-पिता या सहोदरों को प्रभावित किए। तथापि, यदि एक fork() का उपयोग किया जाता है बिना एक नया कैनेरी बनाए, तो सभी प्रक्रियाएँ (माता-पिता और बच्चे) एक ही कैनेरी को साझा करती हैं**, जिससे यह संक्रमित हो जाता है। i386 आर्किटेक्चर पर, कैनेरी gs:0x14 पर संग्रहित होती है, और x86_64 पर, fs:0x28 पर होती है।
यह स्थानीय सुरक्षा उन फ़ंक्शनों को पहचानती है जिनमें हमले के लिए संक्रमित बफर होता है और इन फ़ंक्शनों की शुरुआत पर कैनेरी रखने के लिए कोड डालती है, और इसकी पूर्ति सत्यापित करने के लिए इन फ़ंक्शनों के अंत में कोड डालती है।
जब एक वेब सर्वर fork() का उपयोग करता है, तो यह एक ब्रूट-फोर्स हमला संभावित बनाता है जिसमें कैनेरी बाइट को बाइट के रूप में अनुमानित किया जा सकता है। हालांकि, fork() के बाद execve() का उपयोग करने से मेमोरी स्थान को अधिग्रहण कर दिया जाता है, जिससे हमला निराकरण हो जाता है। vfork() बच्चे प्रक्रिया को डुप्लिकेशन किए बिना निष्पादित करने की अनुमति देता है जब तक वह लिखने का प्रयास नहीं करता, जिसके बाद एक डुप्लिकेट बनाया जाता है, यह प्रक्रिया निर्माण और मेमोरी हैंडलिंग के लिए एक विभिन्न दृष्टिकोण प्रदान करता है।
लंबाई
x64 बाइनरी में, कैनेरी कुकी एक 0x8 बाइट क्वॉर्ड होती है। पहले सात बाइट यादृच्छिक होते हैं और आखिरी बाइट एक नल बाइट होती है।
x86 बाइनरी में, कैनेरी कुकी एक 0x4 बाइट डवर्ड होती है। पहले तीन बाइट यादृच्छिक होते हैं और आखिरी बाइट एक नल बाइट होती है।
दोनों कैनेरी की कमजोर बाइट एक नल बाइट है क्योंकि यह निचले पतों से आने वाले स्टैक में पहला होगा और इसलिए वे फ़ंक्शन जो स्ट्रिंग पढ़ते हैं, उसे पढ़ने से पहले रुक जाएंगे।
बायपास
कैनेरी को लीक करना और फिर इसे ओवरराइट करना (उदाहरण के लिए बफर ओवरफ्लो) अपने ही मान से।
अगर कैनेरी बच्चे प्रक्रियाओं में फॉर्क होती है तो यह संभावना है कि इसे एक बाइट के रूप में ब्रूट-फोर्स किया जा सकता है:
[bf-forked-stack-canaries.md](bf-forked-stack-canaries ## संदर्भ
Last updated