Heap Overflow

Reading time: 8 minutes

Basic Information

Heap overflow एक stack overflow की तरह है लेकिन heap में। मूल रूप से इसका मतलब है कि heap में कुछ डेटा स्टोर करने के लिए कुछ स्थान आरक्षित किया गया था और स्टोर किया गया डेटा आरक्षित स्थान से बड़ा था।

Stack overflows में हम जानते हैं कि कुछ रजिस्टर जैसे कि instruction pointer या stack frame को stack से पुनर्स्थापित किया जाएगा और इसे दुरुपयोग करना संभव हो सकता है। Heap overflows के मामले में, डिफ़ॉल्ट रूप से heap chunk में कोई संवेदनशील जानकारी स्टोर नहीं की जाती जिसे ओवरफ्लो किया जा सके। हालाँकि, यह संवेदनशील जानकारी या पॉइंटर्स हो सकती है, इसलिए इस भेद्यता की गंभीरता इस पर निर्भर करती है कि कौन सा डेटा ओवरराइट किया जा सकता है और एक हमलावर इसे कैसे दुरुपयोग कर सकता है।

Stack Overflows vs Heap Overflows

Stack overflows में उस समय stack में मौजूद डेटा और व्यवस्था जब भेद्यता को सक्रिय किया जा सकता है, काफी विश्वसनीय होती है। इसका कारण यह है कि stack रैखिक है, हमेशा टकराते हुए मेमोरी में बढ़ता है, कार्यक्रम के चलने के विशिष्ट स्थानों पर stack मेमोरी आमतौर पर समान प्रकार के डेटा को स्टोर करती है और इसमें प्रत्येक फ़ंक्शन द्वारा उपयोग किए जाने वाले stack भाग के अंत में कुछ पॉइंटर्स के साथ कुछ विशिष्ट संरचना होती है।

हालांकि, heap overflow के मामले में, उपयोग की गई मेमोरी रैखिक नहीं होती है बल्कि आवंटित चंक्स आमतौर पर मेमोरी के अलग-अलग स्थानों में होते हैं (एक के बगल में नहीं) क्योंकि आकार के अनुसार आवंटनों को अलग करने के लिए बिन और ज़ोन होते हैं और क्योंकि पिछली मुक्त मेमोरी का उपयोग किया जाता है नए चंक्स को आवंटित करने से पहले। यह जानना जटिल है कि कौन सा ऑब्जेक्ट उस ऑब्जेक्ट के साथ टकराने वाला है जो heap overflow के लिए संवेदनशील है। इसलिए, जब एक heap overflow पाया जाता है, तो यह आवश्यक है कि वांछित ऑब्जेक्ट को मेमोरी में अगले स्थान पर लाने का एक विश्वसनीय तरीका खोजा जाए।

इसके लिए उपयोग की जाने वाली तकनीकों में से एक है Heap Grooming जिसे उदाहरण के लिए इस पोस्ट में उपयोग किया गया है। पोस्ट में यह समझाया गया है कि जब iOS कर्नेल में एक ज़ोन में मेमोरी खत्म हो जाती है, तो यह इसे एक कर्नेल पृष्ठ द्वारा बढ़ाता है, और यह पृष्ठ अपेक्षित आकार के चंक्स में विभाजित होता है जो क्रम में उपयोग किए जाएंगे (iOS संस्करण 9.2 तक, फिर ये चंक्स इन हमलों के शोषण को कठिन बनाने के लिए यादृच्छिक तरीके से उपयोग किए जाते हैं)।

इसलिए, पिछले पोस्ट में जहां heap overflow हो रहा है, ओवरफ्लो किए गए ऑब्जेक्ट को एक पीड़ित ऑर्डर के साथ टकराने के लिए मजबूर करने के लिए, कई kallocs को कई थ्रेड्स द्वारा मजबूर किया जाता है ताकि यह सुनिश्चित किया जा सके कि सभी मुक्त चंक्स भरे हुए हैं और एक नया पृष्ठ बनाया गया है।

विशिष्ट आकार के ऑब्जेक्ट के साथ इस भराई को मजबूर करने के लिए, iOS mach port से संबंधित आउट-ऑफ-लाइन आवंटन एक आदर्श उम्मीदवार है। संदेश के आकार को तैयार करके, kalloc आवंटन के आकार को सटीक रूप से निर्दिष्ट करना संभव है और जब संबंधित mach port नष्ट होता है, तो संबंधित आवंटन तुरंत kfree पर वापस जारी किया जाएगा।

फिर, इनमें से कुछ प्लेसहोल्डर्स को मुक्त किया जा सकता है। kalloc.4096 मुक्त सूची तत्वों को अंतिम-में-प्रथम-से-आदेश में जारी करती है, जिसका मूल रूप से मतलब है कि यदि कुछ प्लेसहोल्डर्स को मुक्त किया जाता है और शोषण कई पीड़ित ऑब्जेक्ट्स को आवंटित करने की कोशिश करता है जबकि ओवरफ्लो के लिए संवेदनशील ऑब्जेक्ट को आवंटित करने की कोशिश करता है, तो यह संभावना है कि यह ऑब्जेक्ट एक पीड़ित ऑब्जेक्ट द्वारा अनुसरण किया जाएगा।

Example libc

इस पृष्ठ में एक बुनियादी Heap overflow अनुकरण पाया जा सकता है जो दिखाता है कि अगले चंक के prev in use बिट और prev size की स्थिति को ओवरराइट करके एक उपयोग किए गए चंक को समेकित करना (इसे अप्रयुक्त समझाना) और फिर से इसे आवंटित करना संभव है जिससे डेटा को ओवरराइट किया जा सके जो एक अलग पॉइंटर में भी उपयोग किया जा रहा है।

protostar heap 0 से एक और उदाहरण एक बहुत बुनियादी CTF का उदाहरण दिखाता है जहां heap overflow का दुरुपयोग करके विजेता फ़ंक्शन को कॉल किया जा सकता है फ्लैग प्राप्त करने के लिए।

protostar heap 1 उदाहरण में यह देखा जा सकता है कि एक बफर ओवरफ्लो का दुरुपयोग करके एक निकट चंक में एक पता ओवरराइट करना संभव है जहां उपयोगकर्ता से मनमाना डेटा लिखा जाएगा।

Example ARM64

पृष्ठ https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/ में आप एक heap overflow उदाहरण पा सकते हैं जहां एक कमांड जो निष्पादित होने वाली है, ओवरफ्लो किए गए चंक से अगले चंक में स्टोर की गई है। इसलिए, इसे एक आसान शोषण जैसे कि ओवरराइट करके निष्पादित कमांड को संशोधित करना संभव है:

python3 -c 'print("/"*0x400+"/bin/ls\x00")' > hax.txt

अन्य उदाहरण

• Auth-or-out. Hack The Box
• हम Heap Overflow प्राप्त करने के लिए एक Integer Overflow भेद्यता का उपयोग करते हैं।
• हम एक struct के अंदर एक फ़ंक्शन के लिए पॉइंटर्स को भ्रष्ट करते हैं जो ओवरफ्लो किए गए चंक में है ताकि system जैसे फ़ंक्शन को सेट किया जा सके और कोड निष्पादन प्राप्त किया जा सके।

वास्तविक-विश्व उदाहरण: CVE-2025-40597 – __sprintf_chk का दुरुपयोग

SonicWall SMA100 फर्मवेयर 10.2.1.15 में रिवर्स-प्रॉक्सी मॉड्यूल mod_httprp.so एक 0x80-बाइट हीप चंक आवंटित करता है और फिर इसमें कई स्ट्रिंग्स को __sprintf_chk के साथ जोड़ता है:

char *buf = calloc(0x80, 1);
/* … */
__sprintf_chk(buf,               /* destination (0x80-byte chunk) */
-1,                /* <-- size argument   !!! */
0,                 /* flags */
"%s%s%s%s",      /* format */
"/", "https://", path, host);

__sprintf_chk FORTIFY_SOURCE का हिस्सा है। जब यह सकारात्मक size पैरामीटर प्राप्त करता है, तो यह सुनिश्चित करता है कि परिणामी स्ट्रिंग गंतव्य बफर के अंदर फिट हो। -1 (0xFFFFFFFFFFFFFFFF) पास करके, डेवलपर्स ने प्रभावी रूप से बाउंड्स चेक को अक्षम कर दिया, सुरक्षित sprintf को फिर से एक क्लासिक, असुरक्षित कॉल में बदल दिया।

इसलिए एक अत्यधिक लंबा Host: हेडर प्रदान करने से एक हमलावर 0x80-बाइट चंक को ओवरफ्लो कर सकता है और अगले हीप चंक के मेटाडेटा को क्लॉबर कर सकता है (tcache / fast-bin / small-bin आवंटक के आधार पर)। एक क्रैश को निम्नलिखित के साथ पुन: उत्पन्न किया जा सकता है:

import requests, warnings
warnings.filterwarnings('ignore')
requests.get(
'https://TARGET/__api__/',
headers={'Host': 'A'*750},
verify=False
)

व्यावहारिक शोषण के लिए heap grooming की आवश्यकता होगी ताकि एक नियंत्रित वस्तु कमजोर हिस्से के ठीक बाद रखी जा सके, लेकिन मूल कारण दो महत्वपूर्ण बातें उजागर करता है:

1. _FORTIFY_SOURCE कोई जादुई समाधान नहीं है – दुरुपयोग सुरक्षा को नष्ट कर सकता है।
2. हमेशा _chk परिवार को सही बफर आकार पास करें (या, और भी बेहतर, snprintf का उपयोग करें)।

References

• watchTowr Labs – Stack Overflows, Heap Overflows and Existential Dread (SonicWall SMA100)