shell code on minix - Minix

This is a discussion on shell code on minix - Minix ; I have a pretty standard code to spawn a shell(to be used for buffer overflow attacks). /*A program that creates a file containing code for launching shell*/ #include #include const char code[] = "\x31\xc0" /* xorl %eax,%eax */ "\x50" /* ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: shell code on minix

  1. shell code on minix

    I have a pretty standard code to spawn a shell(to be used for buffer
    overflow attacks).

    /*A program that creates a file containing code for launching shell*/
    #include
    #include

    const char code[] =
    "\x31\xc0" /* xorl %eax,%eax */
    "\x50" /* pushl %eax */
    "\x68""//sh" /* pushl $0x68732f2f */
    "\x68""/bin" /* pushl $0x6e69622f */
    "\x89\xe3" /* movl %esp,%ebx */
    "\x50" /* pushl %eax */
    "\x53" /* pushl %ebx */
    "\x89\xe1" /* movl %esp,%ecx */
    "\x99" /* cdql */
    "\xb0\x0b" /* movb $0x0b,%al */
    "\xcd\x80" /* int $0x80 */
    ;

    int main(int argc, char **argv)
    {
    char buf[sizeof(code)];
    strcpy(buf, code);
    ((void(*)( ))buf)( );
    }

    This works fine on Linux and does spawns a shell.(compiled with gcc)

    On Minix3.1.2a, the compilation fails saying that _buf is undefined.
    Does Minix have a non executable stack by default? or is there
    something different in the way symbols are treated by the CC compiler?

    Could you please point me to the right literature/code where I can get
    a definitive answer?

    -Sridhar.


  2. Re: shell code on minix

    I installed gcc3.4 on minix3.1.2a which compiles the program without
    errors which implies that symbol table construction by the two
    compilers may be different.

    The program however fails with a "Memory fault- core dumped". Does
    that mean that stack is not executable? Again, any piece of code/
    literature will be great.

    -Sridhar


  3. Re: shell code on minix

    Sridhar wrote:
    [...]
    > This works fine on Linux and does spawns a shell.(compiled with gcc)
    >
    > On Minix3.1.2a, the compilation fails saying that _buf is undefined.
    > Does Minix have a non executable stack by default? or is there
    > something different in the way symbols are treated by the CC compiler?


    Minix is different. (I think. I could be wrong; this is certainly how it used
    to work on Minix 2. Minix 3 may be different.)

    On Minix, your application's code and data live in different address spaces.
    You can't simply cast a data pointer into a function pointer (which, BTW, the
    C standard doesn't let you do --- it just happens to work on most other
    systems) and call it. The same value of pointer will in fact point at
    different things.

    In addition, the ACK is trying to stop you using a label pointing at data as
    if it were a function. I'm not sure it's getting it right in the example you
    give --- it's putting buf (the function) in a different address space to buf
    (the array) --- but the only way I managed to trick it into compiling your
    code was to split it up into three files: one with a definition of buf in it,
    one which declares it as an extern array and copies the exploit in, and one
    which declares it as a function and calls it.

    The program hung. (You do know that Minix uses different syscalls to Linux,
    right?)

    --
    ┌── dg*cowlark.com ─── http://www.cowlark.com ──────────────── ──
    │ "Wizards get cranky, / Dark days dawn, / Riders smell manky, / The road
    │ goes on. / Omens are lowering, / Elves go West; / The Shire needs
    │ scouring, / You may as well quest." - John M. Ford

  4. Re: shell code on minix

    In article <1173282021.340998.101580@v33g2000cwv.googlegroups. com>,
    Sridhar wrote:
    >int main(int argc, char **argv)
    >{
    > char buf[sizeof(code)];
    > strcpy(buf, code);
    > ((void(*)( ))buf)( );
    >}
    >
    >This works fine on Linux and does spawns a shell.(compiled with gcc)
    >
    >On Minix3.1.2a, the compilation fails saying that _buf is undefined.
    >or is there
    >something different in the way symbols are treated by the CC compiler?


    Yes. It does compile if you use a function pointer variable and assign buf
    to that pointer.

    However, the default memory model for Minix is separate I&D, so you code can't
    be executed. Compiling with common I&D still doesn't work because the shell
    code is wrong for Minix.


    --
    That was it. Done. The faulty Monk was turned out into the desert where it
    could believe what it liked, including the idea that it had been hard done
    by. It was allowed to keep its horse, since horses were so cheap to make.
    -- Douglas Adams in Dirk Gently's Holistic Detective Agency

  5. Re: shell code on minix

    Sridhar wrote:
    > I installed gcc3.4 on minix3.1.2a which compiles the program without
    > errors which implies that symbol table construction by the two
    > compilers may be different.
    >
    > The program however fails with a "Memory fault- core dumped". Does
    > that mean that stack is not executable? Again, any piece of code/
    > literature will be great.


    I wonder if that piece of code really works as you expect.

    The stack (or data) segment in a i386 processor are not executable and
    analyzing in details the assembler generated in the Minix and Linux
    you may see what trick are used and why it works on Linux. I'm sorry,
    but I.m not familiar with gcc assembler.

    It doubt that the compiler is so smart that it changes the segment
    descriptors (it won't work) but I suppose that it may use some
    capability of the ELF format used in Linux.

    The stack segment could be described twice. As stack and as text
    segment. The Minix format does not have such feature.

    Reading any book on the i386 family of processors would be of help to
    understand how memory protection and allocation works.

    Ciao
    Giovanni
    --
    A computer is like an air conditioner,
    it stops working when you open Windows.
    Registered Linux user #337974 < http://giovanni.homelinux.net/ >

  6. Re: shell code on minix

    On Mar 7, 12:00 pm, phi...@ue.aioy.eu (Philip Homburg) wrote:

    > However, the default memory model for Minix is separate I&D, so you code can't
    > be executed. Compiling with common I&D still doesn't work because the shell
    > code is wrong for Minix.


    I did not quite get the idea of a separate I & D so I went back and
    read some code and the book. The new_mem() function in pm/exec.c
    allocates contiguous memory with the following structure:


    +-------+------------------+-------------------------+---------+
    | Text | Data (Heap) | ---> GAP <------| Stack |
    +-------+------------------+-------------------------+---------+

    What exactly do you mean by separate I and D? Does it mean that text
    and data segements need not be contiguous in the memory(phys or
    virtual)?
    I feel that they occur in contiguous memory locations but different
    virtual address spaces because both mp_seg[T].mem_vir and
    mp_seg[D].mem_vir =0. (Although they are contiguous in M68K
    architecture)

    I am trying stack and heap randomization on Minix3.1.2a. Stack
    randomization is quite easy. I just allocated extra randomClicks and
    added that to mp_seg[S]'s vir and phys addresses. How might I
    randomize the heap if it starts from 0 everytime?

    Lastly is there a shellcode for minix3 out there? I tried plugging in
    the right value of exec syscall in the shell code for linux but it
    didnt work(of course)

    Sridhar


  7. Re: shell code on minix

    All,

    > What exactly do you mean by separate I and D? Does it mean that text
    > and data segements need not be contiguous in the memory(phys or
    > virtual)?


    It means the text and data segments point to different areas of memory,
    and jumps and the like are always relative to the text area, and data
    and stack are always relative to the data area. So executable code in
    the data segment will never be executed as it can't be addressed from
    the text segment.

    You can compile binaries to have shared I&D, however.

    =Ben



  8. Re: shell code on minix

    On Mar 11, 6:46 am, Ben Gras wrote:

    So executable code in
    > the data segment will never be executed as it can't be addressed from
    > the text segment.


    So it is safe to assume that there will be no buffer overflow
    attacks?

    Sridhar


  9. Re: shell code on minix

    All,

    >> So executable code in
    >> the data segment will never be executed as it can't be addressed from
    >> the text segment.

    >
    > So it is safe to assume that there will be no buffer overflow
    > attacks?


    No, not quite. Firstly, it's a matter of how the binary was compiled -
    it can be compiled with shared I&D.

    Secondly, although I'm no expert in the countless ways to exploit a
    buffer overflow, there is more than enough mischief you can do with it
    that doesn't involve writing code on the stack and executing it.

    =Ben



  10. Re: shell code on minix


    "Sridhar" writes:

    > On Mar 11, 6:46 am, Ben Gras wrote:
    >
    > So executable code in
    >> the data segment will never be executed as it can't be addressed from
    >> the text segment.

    >
    > So it is safe to assume that there will be no buffer overflow
    > attacks?


    Probably this cannot be safely assumed: For one thing, there might be
    common I&D programs araound and they would be vulnerable.

    For another thing: Buffer overflow attacks can be more sophisticated
    than just dumping shell code on the stack and smuggling a return
    address to the very same shell code into the stack frame. You'd have
    to consult relevant writings on that (attack techniques are not well
    documented and after various repeated attempts of national governments
    to outlaw "hacker tools" and dangerous knowledge (see e.g. the
    reprecussions of the DMCA), it is less and less likely that those that
    don't work for the dark side will put efforts into making themselves a
    convenient target -- and those on the dark side obviously have no
    interest in publically available documentation anyway. But I
    disgress).

    From the top of my head I can imaging some techniques in a multiple
    I&D environment that might work from time to time: Creative use of
    code that is already present in the ececutable, i.e. if there is an
    invokation of system() or exec*("/bin/sh",...) somewhere you can try
    to jump to that place. Also there might be a possibility to jump on a
    piece of code in the C segment that might just happen to be the
    opcode sequence for a far return -- will pop CS:IP from the stack --
    and voila, since you control the stack, you'll be abel to start
    executing DS (if the executable but is set, that is).

    The "can't be addresses from text segement" is (I might be mistaken),
    just a pointer length issue. Regular returns from procedures just pop
    IP from the stack, so you stay in the current CS. But you might just
    force a jump to place where a inter-segment return is coded (maybe
    accidentally, in reality the bytes might be intented to mean something
    else) and thus you can force loading CS:IP.

    Am I clear?

    If I missed something I'd be happy to hear from others here whose
    views on that matter differ.

    Regards -- Markus




+ Reply to Thread