3

I'm currently reading Gray Hat Hacking The Ethical Hacker's Handbook, Fourth Edition and I have a question with an exercise in the book. The lab "Lab 10 - 1 Overflow of meet.c" is a lab in which we perform a buffer overflow in the program. The program is as follow:

//meet.c
#include <stdio.h>   // needed for screen printing
#include <string.h>

greeting(char *temp1,char *temp2){ // greeting function to say hello
   char name[400];    // string variable to hold the name
   strcpy(name, temp2);    // copy the function argument to name
   printf("Hello %s %s\n", temp1, name); // print out the greeting
}
main(int argc, char * argv[]){      // note the format for arguments
   greeting(argv[1], argv[2]);      // call function pass title & name
   printf("Bye %s %s\n", argv[1], argv[2]);   // say "bye"
} // exit program

The book informs you to compile the code with:

gcc -ggdb -mpreferred-stack-boundary=2 -fno-stack-protector -z execstack -o meet meet.c

I'm not too sure what each argument pass to the compiler mean I read from the man page that mpreferred-stack-boundary attempts to aligned the stack boundary in this case 2 ^ 2 = 4 bytes. I've seen the no stack protector flag used before so I know that it allows smashing of the stack and the -z execstack I want to believe is to make data executable form the stack (removing the NX bit).

And prior to all this we already disabled ASLR using the command:

echo "0" > /proc/sys/kernel/randomize_va_space

The book also mention to disable the following:

echo "0" > /proc/sys/kernel/exec-shield
echo "0" > /proc/sys/kernel/exec-shield-randomize

I didn't find these files in the specified directory so I didn't run the command I was curious if this was causing my issue so I googled it and found this forum post:

http://ubuntuforums.org/showthread.php?t=1945764

But the forum post stated that the arguments we past to the compiler already takes care of disabling the "exec-shield" feature and the "exec-shield-randomize" feature.

So the issue I am having is when I follow the book instructions I receive different results from the book.

The book said the stack frame would resemble this:

                         Function
                         Variable                            Parameters
______________________________________________________________________________
|           |    ESP   |    Name   |   EBP   |   EIP   |   Temp1   |   Temp2  |
-------------------------------------------------------------------------------
Low Mem:               <--------- Stack Grow                         High Mem:
0x11111111                                                        0xfffffff0

They then loaded the program in gnu debugger with the following command:

gdb -q meet

They then placed a breakpoint on line 7:

strcpy(name, temp2);

An passed the overflow argument value using perl:

(gdb) run Mr perl -e 'print "A" x 600'

For that the got the following output:

Breakpoint 1, greeting (temp1=0x41414141 <Address 0x41414141 out of bounds>,
    temp2=0x41414141 <Address 0x41414141 out of bounds>) at meet.c:7
          printf("Hello %s %s\n",temp1, name); //print out the greeting

So they successfully written over the EIP register, temp1 and temp2 pointers as the book said but when I tried it I got this:

my gdb output

I tried 600, 1,000, 10,000, and as you can see in the screenshot 100,000 A's. So can someone tell me if I am doing something wrong am I forgeting to disable a security feature or something like that?

OS info:

Ubunut 14.04 Linux ubuntu 3.19.0-49-generic #55~14.04.1-Ubuntu SMP Fri Jan 22 11:23:34 UTC 2016 i686 i686 i686 GNU/Linux

UPDATE:

This is the book results: Gray Hat BOF breakpoint result

The book state that now the pointers temp1 and temp2 are overwritten and now points to null for me this didn't happen. Why?

  • What do your registers look like when the crash happens? – Dirk Feb 24 '16 at 13:24
  • Have you noticed, that despite of your x 100000 in the command line, gdb says 'A' <repeats 200 times>? – ott-- Feb 24 '16 at 15:40
  • @ott-- yea I noticed hence the reason I believe it was due to some security feature I forgot to disabled. I'm at work right now I will take a look at everyone's response in depth when I reach home. – user1803784 Feb 24 '16 at 16:09
  • @PolymathMonkey do you want me to crash the program with any number of A's because 600 A's also crashes the program my concern is why i don't get the results the book gets. The book has the temp1 & temp2 variable addresss being all A's (0x41) im just wondering why this is not happening for me. – user1803784 Feb 25 '16 at 0:44
3

Your screenshot shows that gdb has hit the breakpoint, Temp1 and temp2 aren't overwritten yet because you are hitting a breakpoint on strcpy which halts execution before strcpy overwrites the stack. As per your book image you can see that their line 7 is printf which happens after strcpy corrupts the stack. Try using the c gdb command to continue. Eip control occurs in the epilogue, when the function returns.

  • Yea I understand what you're saying I blieve. You're saying that EIP controls occur after the function call has finish, in which it clears the stack form the value placed on it from its function call and return (EIP) to the next line from which it made the call from right? I really want to know why temp 1 & temp2 is not overwritten because its messing up my understanding of how the stack works (with security features disabled). I will provide an excerpt with the book results. – user1803784 Feb 25 '16 at 0:55
  • 1
    Temp1 and temp2 aren't overwritten yet because you are hitting a breakpoint on strcpy which halts execution before strcpy overwrites the stack. As per your book image you can see that their line 7 is printf which happens after strcpy corrupts the stack. – wireghoul Feb 25 '16 at 1:14
  • (FACEPALM) yup that is exactly what i was looking for. One extra line i made in my code I thought the source i had was identical to what was in the book. It went out of sync when i added an extra line before the main declaration. none the less thank you soooooooo much. Can you modify your answer so I check this off as the solution. – user1803784 Feb 25 '16 at 1:21
3

One side note not directly related to the problem :

I'm not sure if the book you're using is the best to start your pentesting\exploit development with. I would recommend OSCP's hands-on or Georgia weidman's book "Penetration testing A Hands-On Introduction to Hacking"
Or you can try SEED project's labs.

Now i'm not sure i can tell what is going wrong without trying the lab (Which i'll try do and get back to you). However, I can tell you that increasing the buffer's size is not always the answer. In fact, it sometimes corrupts your exploit because your extra long buffer might overwrite the caller's function data causing the app to call the exception handler which -if happened -will move the address of the exception handler function to the EIP, and will force you to do things in a different way to overwrite the EIP because now the address of the exception handler is in the EIP, not your buffer .

  • Thanks for the tips on the hands-on and books will take a look into them. I understand what you are saying. I understand the exploit is to overwrite EIP value and if i increase the buffer that would cause the address of the exception handler to be placed in the EIP instead; thanks for that explanation. I eventual want to overwrite the EIP to get the exploit working but I'm wondering why doesn't temp1 & temp2 address don't get overwritten I don't believe the stack frame is that large right? hence the reason I am increasing the size just to see if I can overwrite the address of temp1 and temp2. – user1803784 Feb 24 '16 at 5:29
  • I've added some info about my OS basically the output of uname -r command. – user1803784 Feb 24 '16 at 5:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.