ASLR
मूल जानकारी
Address Space Layout Randomization (ASLR) एक सुरक्षा तकनीक है जो ऑपरेटिंग सिस्टम में उपयोग की जाती है ताकि सिस्टम और एप्लिकेशन प्रक्रियाओं द्वारा उपयोग किए जाने वाले मेमोरी पतों को रैंडमाइज़ करें। इसके द्वारा, यह किसी हमलावादी को विशेष प्रक्रियाओं और डेटा के स्थान का पूर्वानुमान करना काफी कठिन बना देता है, जैसे स्टैक, हीप, और लाइब्रेरी, इस प्रकार के कुछ प्रकार के उत्पीड़न को कम करता है, विशेषकर बफर ओवरफ्लोज़।
ASLR स्थिति की जाँच
Linux सिस्टम पर ASLR स्थिति की जाँच करने के लिए, आप /proc/sys/kernel/randomize_va_space
फ़ाइल से मान पढ़ सकते हैं। इस फ़ाइल में स्टोर किया गया मान यह तय करता है कि कौन सा प्रकार का ASLR लागू हो रहा है:
0: कोई रैंडमाइज़ेशन नहीं। सब कुछ स्थैतिक है।
1: सतर्क रैंडमाइज़ेशन। साझा लाइब्रेरी, स्टैक, mmap(), VDSO पेज रैंडमाइज़ हैं।
2: पूर्ण रैंडमाइज़ेशन। सतर्क रैंडमाइज़ेशन द्वारा रैंडमाइज़ किए गए तत्वों के अतिरिक्त,
brk()
के माध्यम से प्रबंधित मेमोरी भी रैंडमाइज़ है।
आप निम्नलिखित कमांड के साथ ASLR स्थिति की जाँच कर सकते हैं:
ASLR को अक्षम करना
ASLR को अक्षम करने के लिए, आप /proc/sys/kernel/randomize_va_space
के मान को 0 पर सेट करते हैं। ASLR को अक्षम करना सामान्यतः टेस्टिंग या डीबगिंग स्थितियों के बाहर सुझावित नहीं है। यहाँ दिया गया है कि आप इसे कैसे अक्षम कर सकते हैं:
आप एक निष्पादन के लिए ASLR को अक्षम कर सकते हैं:
ASLR सक्षम करना
ASLR को सक्षम करने के लिए, आप /proc/sys/kernel/randomize_va_space
फ़ाइल में मान 2 लिख सकते हैं। यह आम तौर पर रूट विशेषाधिकारों की आवश्यकता होती है। पूर्ण यादृच्छिकता को निम्नलिखित कमांड के साथ सक्षम किया जा सकता है:
पुनः बूट के अवस्थान
echo
कमांड के साथ किए गए परिवर्तन अस्थायी होते हैं और पुनः बूट के समय रीसेट हो जाते हैं। परिवर्तन स्थायी बनाने के लिए, आपको /etc/sysctl.conf
फ़ाइल में संपादन करना होगा और निम्नलिखित पंक्ति जोड़नी या संशोधित करनी होगी:
प्रभावित करने के लिए /etc/sysctl.conf
को संपादित करने के बाद, निम्नलिखित के साथ परिवर्तन लागू करें:
यह सुनिश्चित करेगा कि आपकी ASLR सेटिंग्स पुनरारंभ होने पर भी बनी रहें।
बाईपास
32बिट ब्रूट-फोर्सिंग
PaX प्रक्रिया पता स्थान क्षेत्र को 3 समूहों में विभाजित करता है:
कोड और डेटा (सक्रिय और असक्रिय):
.text
,.data
, और.bss
—>delta_exec
चर में 16 बिट का अनियमितता। इस चर को प्रत्येक प्रक्रिया के साथ यादृच्छिक रूप से प्रारंभ किया जाता है और प्रारंभिक पतों में जोड़ा जाता है।mmap()
द्वारा आवंटित स्मृति और साझा पुस्तकालय —> 16 बिट, जिसेdelta_mmap
नामक किया गया है।स्टैक —> 24 बिट,
delta_stack
के रूप में संदर्भित। हालांकि, यह वास्तव में 11 बिट का उपयोग करता है (10वें से 20वें बाइट समाविष्ट), 16 बाइट के अनुरूप संरेखित किया गया है —> इससे 524,288 संभावित वास्तविक स्टैक पते होते हैं।
पिछले डेटा 32-बिट सिस्टमों के लिए है और कम होने वाली अंतिम अनियमितता के कारण ASLR को बाईपास करना संभव होता है, जब तक उत्पीड़न सफलतापूर्वक पूरा न हो जाए।
ब्रूट-फोर्स विचार:
यदि आपके पास एक बड़ा पर्याप्त ओवरफ्लो है जिसमें शेलकोड से पहले एक बड़ा NOP स्लेड हो सकता है, तो आप स्टैक में पतों को ब्रूट-फोर्स कर सकते हैं जब तक फ्लो NOP स्लेड के किसी हिस्से पर छलांग नहीं मारता।
इसके लिए एक और विकल्प यदि ओवरफ्लो इतना बड़ा नहीं है और उत्पीड़न स्थानीय रूप से चलाया जा सकता है तो संभावना है कि एनओपी स्लेड और शेलकोड को एक पर्यावरण चर में जोड़ा जा सकता है।
यदि उत्पीड़न स्थानीय है, तो आप libc के आधार पते को ब्रूट-फोर्स करने का प्रयास कर सकते हैं (32बिट सिस्टमों के लिए उपयोगी):
अगर आप एक रिमोट सर्वर पर हमला कर रहे हैं, तो आप
libc
फ़ंक्शनusleep
का पता लगाने के लिए ब्रूट-फ़ोर्स कर सकते हैं, उदाहरण के लिए 10 को एर्ग्यूमेंट के रूप में पास करें। अगर किसी समय सर्वर 10 सेकंड अतिरिक्त समय लेता है तो आपने इस फ़ंक्शन का पता लगा लिया है।
64 बिट सिस्टम में एंट्रोपी अधिक होती है और यह संभव नहीं होना चाहिए।
64 बिट स्टैक ब्रूट-फ़ोर्सिंग
यह संभव है कि आप env variables के साथ स्टैक का बड़ा हिस्सा अधिक करें और फिर इसे उसका शोषण करने के लिए स्थानीय रूप से शत्रुता करने की कोशिश करें। निम्नलिखित कोड दिखाता है कि स्टैक में एक पता का चयन करना संभव है और हर कुछ सैकड़ों बार के बाद उस पते में NOP इंस्ट्रक्शन होगा:
स्थानीय सूचना (/proc/[pid]/stat
)
/proc/[pid]/stat
)प्रक्रिया का फ़ाइल /proc/[pid]/stat
हमेशा सभी द्वारा पढ़ी जा सकती है और इसमें रोचक जानकारी शामिल है जैसे:
startcode & endcode: ऊपर और नीचे पता है जिसमें बाइनरी का TEXT है
startstack: stack की शुरुआत का पता
start_data & end_data: ऊपर और नीचे पता है जहां BSS है
kstkesp & kstkeip: वर्तमान ESP और EIP पते
arg_start & arg_end: ऊपर और नीचे पता है जहां cli arguments हैं।
env_start & env_end: ऊपर और नीचे पता है जहां env variables हैं।
इसलिए, यदि हमलावर उसी कंप्यूटर में है जिसमें बाइनरी है और यह बाइनरी कच्चे तर्क से अधिक अपेक्षित नहीं है, लेकिन एक विभिन्न इनपुट से अधिक भराई जा सकती है जो इस फ़ाइल को पढ़ने के बाद बनाया जा सकता है। एक हमलावर को इस फ़ाइल से कुछ पते प्राप्त करने और उससे अभिशोषण के लिए ऑफसेट निर्मित करने की संभावना है।
इस फ़ाइल के बारे में अधिक जानकारी के लिए https://man7.org/linux/man-pages/man5/proc.5.html पर /proc/pid/stat
खोजें।
एक लीक होना
चुनौती एक लीक देना है
यदि आपको एक लीक मिलता है (सरल CTF चुनौतियाँ), तो आप इससे ऑफसेट की गणना कर सकते हैं (उदाहरण के लिए मान लें कि आप जानते हैं कि आप उस सिस्टम में उपयोग किए जाने वाले सटीक libc संस्करण को)। यह उदाहरण शोध यहाँ से निकाला गया है यहाँ से उदाहरण (अधिक विवरण के लिए उस पृष्ठ की जाँच करें):
ret2plt
एक बफर ओवरफ्लो का दुरुपयोग करके एक ret2plt का शोषण करना संभव होगा ताकि libc से किसी फ़ंक्शन का पता निकाला जा सके। जांच करें:
pageRet2pltफॉर्मेट स्ट्रिंग्स एर्बिट्रेरी रीड
जैसे कि ret2plt में, अगर आपके पास फॉर्मेट स्ट्रिंग्स वलनरबिलिटी के माध्यम से एक विषयस्वी पठन संभावना है तो एक libc फ़ंक्शन का पता निकालना संभव है। निम्नलिखित उदाहरण यहाँ से है:
आप फॉर्मेट स्ट्रिंग अर्बिट्रेरी पढ़ने के बारे में अधिक जानकारी यहाँ पा सकते हैं:
pageFormat StringsRet2ret & Ret2pop
स्टैक के अंदर पते का दुरुपयोग करके ASLR को अवगाहित करने का प्रयास करें:
pageRet2ret & Reo2popvsyscall
vsyscall
तंत्र कुछ सिस्टम कॉल को उपयोगकर्ता स्थान में निष्पादित करने के द्वारा प्रदर्शन को बढ़ाने के लिए सेवित करता है, हालांकि वे मौलिक रूप से कर्नेल का हिस्सा हैं। vsyscalls का महत्वपूर्ण लाभ उनके निश्चित पतों में है, जो ASLR (पता स्थान लेआउट यातायात यादृच्छीकरण) के अधीन नहीं हैं। यह निश्चित स्वभाव यह मानता है कि हमलावरों को उनके पतों का निर्धारण करने और उन्हें एक उत्पीड़न में उपयोग करने के लिए एक जानकारी लीक संकट की आवश्यकता नहीं है।
हालांकि, यहाँ कोई अत्यधिक रोमांचक गैजेट नहीं मिलेगा (हालांकि उदाहरण के लिए एक ret;
समकक्ष प्राप्त किया जा सकता है)
(निम्नलिखित उदाहरण और कोड इस लेख से है)
उदाहरण के रूप में, एक हमलावर एक उत्पीड़न के भीतर पता 0xffffffffff600800
का उपयोग कर सकता है। जबकि सीधे ret
निर्देश को छलकरने का प्रयास करने पर कुछ गैजेट्स को निष्तब्ध करने के बाद अस्थिरता या क्रैश का सामना कर सकता है, तो vsyscall खंड द्वारा प्रदान की गई एक syscall
की शुरुआत पर कूदने का प्रयास सफल साबित हो सकता है। एक ROP गैजेट को सावधानीपूर्वक रखकर जो इस vsyscall पते पर निष्पादन करने की ओर ले जाता है, एक हमलावर इस भाग के लिए ASLR को अवगाहित किए बिना कोड निष्पादन कर सकता है।
vDSO
ध्यान दें कि यदि कर्नेल CONFIG_COMPAT_VDSO के साथ कॉम्पाइल किया गया है, तो vdso का दुरुपयोग करके ASLR को अनदेखा किया जा सकता है क्योंकि vdso पता यादृच्छिक नहीं होगा। अधिक जानकारी के लिए देखें:
pageRet2vDSOLast updated