Can't Produce a buffer overflow

This is a discussion on Can't Produce a buffer overflow within the C Programming forums, part of the General Programming Boards category; Can someone tell me why I can't produce a buffer overflow in this: (and execute the hidden function)? The true ...

  1. #1
    Registered User
    Join Date
    Dec 2007
    Posts
    51

    Can't Produce a buffer overflow

    Can someone tell me why I can't produce a buffer overflow in this: (and execute the hidden function)? The true output is supposted to be -> Hidden

    Code:
    (gdb) list 1,100
    1       #include <stdio.h>
    2       #include <stdlib.h>
    3       #include <string.h>
    4
    5
    6       void func1(char *str1);
    7       void hiddenFunc();
    8
    9
    10      void hiddenFunc()
    11      {
    12
    13              printf("Hidden");
    14      }
    15
    16
    17      void func1(char *str1)
    18      {
    19              char str2[8];
    20
    21              strcpy(str2,str1);
    22
    23
    24      }
    25
    26
    27      int main(int argc, char *argv[])
    28      {
    29              int a,b,c;
    30
    31              printf("Test text");
    32
    33
    34              func1(argv[1]);
    35
    36              return 0;
    37
    38      }
    39
    40
    41
    42
    43
    44
    
    (gdb) disass main
    Dump of assembler code for function main:
    0x080483e2 <main+0>:    lea    0x4(&#37;esp),%ecx
    0x080483e6 <main+4>:    and    $0xfffffff0,%esp
    0x080483e9 <main+7>:    pushl  0xfffffffc(%ecx)
    0x080483ec <main+10>:   push   %ebp
    0x080483ed <main+11>:   mov    %esp,%ebp
    0x080483ef <main+13>:   push   %ebx
    0x080483f0 <main+14>:   push   %ecx
    0x080483f1 <main+15>:   sub    $0x20,%esp
    0x080483f4 <main+18>:   mov    %ecx,%ebx
    0x080483f6 <main+20>:   movl   $0x8048507,(%esp)
    0x080483fd <main+27>:   call   0x80482c8 <printf@plt>
    0x08048402 <main+32>:   mov    0x4(%ebx),%eax
    0x08048405 <main+35>:   add    $0x4,%eax
    0x08048408 <main+38>:   mov    (%eax),%eax
    0x0804840a <main+40>:   mov    %eax,(%esp)
    0x0804840d <main+43>:   call   0x80483c8 <func1>
    0x08048412 <main+48>:   mov    $0x0,%eax
    0x08048417 <main+53>:   add    $0x20,%esp
    0x0804841a <main+56>:   pop    %ecx
    0x0804841b <main+57>:   pop    %ebx
    0x0804841c <main+58>:   pop    %ebp
    0x0804841d <main+59>:   lea    0xfffffffc(%ecx),%esp
    0x08048420 <main+62>:   ret    
    End of assembler dump.
    
    (gdb) disass hiddenFunc
    Dump of assembler code for function hiddenFunc:
    0x080483b4 <hiddenFunc+0>:      push   %ebp
    0x080483b5 <hiddenFunc+1>:      mov    %esp,%ebp
    0x080483b7 <hiddenFunc+3>:      sub    $0x8,%esp
    0x080483ba <hiddenFunc+6>:      movl   $0x8048500,(%esp)
    0x080483c1 <hiddenFunc+13>:     call   0x80482c8 <printf@plt>
    0x080483c6 <hiddenFunc+18>:     leave  
    0x080483c7 <hiddenFunc+19>:     ret    
    End of assembler dump.
    
    (gdb) x/xw &str2
    0xbfd15f00:     0xbfd10041
    
    (gdb) x/64x $esp
    0xbfe5d400:     0xbfe5d410      0xbfe5dbf7      0x08048507      0xbfe5d424
    0xbfe5d410:     0xbfe50041      0xbfe5d460      0xbfe5d448      0x08048412
    0xbfe5d420:     0xbfe5dbf7      0x0024d210      0xbfe5d458      0x08048459
    0xbfe5d430:     0x0013ba55      0xbfe5d4f0      0xbfe5d458      0x0024eff4
    0xbfe5d440:     0xbfe5d460      0x0024eff4      0xbfe5d4b8      0x00125dec
    0xbfe5d450:     0x008b9ca0      0x08048440      0xbfe5d4b8      0x00125dec
    0xbfe5d460:     0x00000002      0xbfe5d4e4      0xbfe5d4f0      0x008ba810
    0xbfe5d470:     0x00000000      0x00000001      0x00000001      0x00000000
    0xbfe5d480:     0x0024eff4      0x008b9ca0      0x00000000      0xbfe5d4b8
    0xbfe5d490:     0x3b4a8b6b      0x84bd02ba      0x00000000      0x00000000
    0xbfe5d4a0:     0x00000000      0x008b2450      0x00125d1d      0x008b9fc0
    0xbfe5d4b0:     0x00000002      0x080482e0      0x00000000      0x08048301
    0xbfe5d4c0:     0x080483e2      0x00000002      0xbfe5d4e4      0x08048440
    0xbfe5d4d0:     0x08048430      0x008ad5c0      0xbfe5d4dc      0x008b5f8b
    0xbfe5d4e0:     0x00000002      0xbfe5dbde      0xbfe5dbf7      0x00000000
    0xbfe5d4f0:     0xbfe5dbf9      0xbfe5dc18      0xbfe5dc28      0xbfe5dc33
    
    ./a.out `perl -e 'print "\xb4\x83\x04\x08"x20'`
    Segmentation fault
    Last edited by someprogr; 09-15-2008 at 07:52 AM.

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    What build of Linux are you using? Does it perhaps have execution protection for the stack? [That is a feature intended to prevent buffer overflow attacks].

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    Registered User
    Join Date
    Dec 2007
    Posts
    51
    Quote Originally Posted by matsp View Post
    What build of Linux are you using? Does it perhaps have execution protection for the stack? [That is a feature intended to prevent buffer overflow attacks].

    --
    Mats
    I'm actually using CentOS 5 Linux version 2.6.18-92.1.10.el5. How do I know if this protection is enabled?

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    You should get a bootmessage like this:
    Code:
    NX (Execute Disable) protection: active
    So if you (on a recently booted system) do "dmesg|grep ^NX", you should get that message (or something similar).

    You can also do:
    Code:
          readelf -l /bin/cat | grep STACK
    if it displays a line like:

    STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4
    then your stack is not marked as executable. If it has RWE on the back end of the line instead of RW, your stack is executable.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #5
    Registered User
    Join Date
    Dec 2007
    Posts
    51
    Quote Originally Posted by matsp View Post
    You should get a bootmessage like this:
    Code:
    NX (Execute Disable) protection: active
    So if you (on a recently booted system) do "dmesg|grep ^NX", you should get that message (or something similar).

    You can also do:
    Code:
          readelf -l /bin/cat | grep STACK
    if it displays a line like:

    STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4
    then your stack is not marked as executable. If it has RWE on the back end of the line instead of RW, your stack is executable.

    --
    Mats

    I got something more like this:

    Code:
    Using x86 segment limits to approximate NX protection
    and

    Code:
    readelf -l /bin/cat | grep STACK
      GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4
    Does this mean I can't smash the stack?

  6. #6
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Actually, it shouldn't prevent you from smashing the stack, just prevent you from putting code on the stack and make the processor execute that.

    Edit: perhaps the problem is that your "fake return address" is not aligned correctly, so the data copied does not actually match up with the return instruciton. But perhaps another plausible scenario is that your seg fault terminates the application before you have a chance to see the printf("hidden") - try adding either a newline on the end or a ffush(stdout). Sorry about the slow edit.

    --
    Mats
    Last edited by matsp; 09-15-2008 at 08:48 AM.
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  7. #7
    Registered User
    Join Date
    Dec 2007
    Posts
    51
    Quote Originally Posted by matsp View Post
    Actually, it shouldn't prevent you from smashing the stack, just prevent you from putting code on the stack and make the processor execute that.

    --
    Mats
    What I was trying to do (change the value of the return address to the hiddenFunc).... is that called stack smashing? And that wouln't be effected by the NX bit anyway right? I only assume this since theres no shellcode to execute...

    When there is shellcode, thats where the NX bit comes in handy?

  8. #8
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Right, I spent several minutes (got interrupted) on adding an edit to the post, so please re-read my previous post.

    The NX bit is there to prevent someone putting their own code on the stack, and then returning to the stack itself, not preventing a change in the return address of the function.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  9. #9
    Registered User
    Join Date
    Dec 2007
    Posts
    51
    Quote Originally Posted by matsp View Post
    Right, I spent several minutes (got interrupted) on adding an edit to the post, so please re-read my previous post.

    The NX bit is there to prevent someone putting their own code on the stack, and then returning to the stack itself, not preventing a change in the return address of the function.

    --
    Mats
    Thanks friend, you've been a lot of help, much appreciated.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 16
    Last Post: 10-29-2006, 04:04 AM
  2. buffer overflow
    By cpp_is_fun in forum C Programming
    Replies: 2
    Last Post: 10-24-2006, 11:04 PM
  3. Buffer overflow errors
    By EvBladeRunnervE in forum C Programming
    Replies: 2
    Last Post: 03-17-2004, 03:58 PM
  4. Buffer overflow issue.
    By caroundw5h in forum C Programming
    Replies: 3
    Last Post: 12-27-2003, 11:13 AM
  5. Console Screen Buffer
    By GaPe in forum Windows Programming
    Replies: 0
    Last Post: 02-06-2003, 04:15 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21