in reply to Finding stack addresses

In pure perl (except for possible bugs in the interpreter) there is no way to get buffer overflows: the interpreter manages the memory for its variables without any direct intervention from the language and will just allocate more memory if you try to extend a string, hash or array. This might fail, ofcourse, but that will just shut down the interpreter with an out of memory error.

In C/XS extensions, there is just as much possibility for buffer overflows as in pure C, because they are basically written in C (give or take a few hundred macros and some other preprocessing).

In other words, it seems to me you're asking for the impossible or the obvious. See perlxs for the obvious answer.

update: to find the top of the perl stack (which is not really where the environment variables are kept) see caller

Replies are listed 'Best First'.
Re^2: Finding stack addresses
by perianmellon (Initiate) on Sep 18, 2006 at 20:56 UTC
    ah yes, I'm sorry I didn't clarify. I'm using perl to exploit another c program that is vulnerable to buffer overflows. My perl program is just constructing the "egg" to feed into my vulnerable program and puts the exploit code into an environment variable. I'm trying to find the address of this variable so I can overflow the buffer in my vulnerable program with it. Thanks for your help!

        I could go into a lot of detail here, but I guess it would be mostly off-topic.

        However generally a successful buffer overflow attack requires two things:

        • A static buffer (keeping things simple) being overwritten such that a function return address on the stack can be modified.
        • A piece of shellcode somewhere in the processes address-space.

        Once you've written past the end of the buffer to be overflowed, and modified the saved "return address" value you want to write the address of your shellcode there. The net result is that once the buffer is overflown your own code gets executed, and you win!

        Traditionally this is done by saving the code to execute in an environmental variable - which will exist in all processes spawned by a parent shell, and which won't move around.

        So the process becomes:

        • run /bin/sh
        • setup the $EGG variable via "export EGG=shellcode..." (remember that environmental variables can contain binary data)
        • Construct an overly long argument/parameter/fileinputand feed it to your vulnerable program - attempting to cause the overritten return address/EIP to be set to getenv( "EGG")
        • Profit!

        Or you could cheat and use a pre-made tool to do all the work ..

        Steve
        --