बफर ओवरफ्लो

Question

के साथ डिलेमा मैं एक स्टैक ओवरफ़्लो उदाहरण के साथ खेल रहा हूं। यह उदाहरण इस तरह दिखता है:

void return_input (void){ 
    char array[30];  
    gets (array); 
    printf("%s\n", array); 

} 

main() { 
    return_input();  
    return 0;  
} 

यह सब कोड overflow.c नामक फ़ाइल में है। हमारे पास कमजोर फ़ंक्शन है return_input, विशेष रूप से यह 30 बाइट चार सरणी है। मैं इसे संकलित और gdb में कमजोर समारोह खोला और मिल गया आउटपुट निम्नलिखित:

(gdb) disas return_input 
0x08048464 <+0>: push %ebp 
0x08048465 <+1>: mov %esp,%ebp 
0x08048467 <+3>: sub $0x48,%esp 
0x0804846a <+6>: mov %gs:0x14,%eax 
0x08048470 <+12>: mov %eax,-0xc(%ebp) 
0x08048473 <+15>: xor %eax,%eax 
0x08048475 <+17>: lea -0x2a(%ebp),%eax 
0x08048478 <+20>: mov %eax,(%esp) 
0x0804847b <+23>: call 0x8048360 <gets@plt> 
0x08048480 <+28>: lea -0x2a(%ebp),%eax 
0x08048483 <+31>: mov %eax,(%esp) 
0x08048486 <+34>: call 0x8048380 <puts@plt> 
0x0804848b <+39>: mov -0xc(%ebp),%eax 
0x0804848e <+42>: xor %gs:0x14,%eax 
0x08048495 <+49>: je  0x804849c <return_input+56> 
0x08048497 <+51>: call 0x8048370 <__stack_chk_fail@plt> 
0x0804849c <+56>: leave 
0x0804849d <+57>: ret  
End of assembler dump. 

आप समारोह प्रस्तावना हम सुरक्षित hex48 (डीईसी 72) से देख स्थानीय चर के लिए स्टैक पर बाइट्स। सबसे पहले मैं उस पते को खोजने की कोशिश कर रहा था जहां हमारी कमजोर सरणी ढेर पर शुरू होती है। मुझे लगता है कि यह -0x2a (% ebp) है, क्या मैं सही हूँ? Hex2a 42 दशमलव है। जैसा कि मैं समझता हूं इसका मतलब है कि हम ढेर पर सहेजे गए ईबीपी को ओवरराइट करना शुरू करने से पहले 42 बाइट्स को सुरक्षित रूप से लिख सकते हैं।

rustam@rustam-laptop:~/temp/ELF_reader$ ./overflow 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 
Segmentation fault (core dumped) 

कैसे 37 बाइट्स पर्याप्त बफर अतिप्रवाह के लिए किया जाता है: लेकिन यह विभाजन गलती प्राप्त करने का अधिकार केवल 37 बाइट्स करने के लिए पर्याप्त है जब मैं इस उदाहरण चलाने? यदि हमारी स्थानीय चार सरणी सहेजी गई ईबीपी

Answer 1

से -42 बाइट्स है, तो फ़ंक्शन के पूरे डिस्सेप्लर को देखे बिना बताना मुश्किल है।

हालांकि, मेरा अनुमान है कि% gs: 0x14 -0xc (% ebp) पर संग्रहीतआपके stack canary हो सकता है जो एक स्टैक अपशिष्ट का पता चला है, तो एक साफ निकास का कारण बनता है। तो यह मान -0xc (% ebp) पर संग्रहीत है, जिसका अर्थ है कि आपका बफर वास्तव में केवल 30 बाइट्स बड़ा है, इसके बाद जो कुछ भी आता है।