OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
silvio_at_big.net.au
Date: Mon Sep 30 2002 - 03:00:03 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    On Mon, Sep 30, 2002 at 07:40:00AM +0100, Dave Wilson wrote:
    > On Sun, Sep 29, 2002 at 10:03:36PM -0700, silviobig.net.au wrote:
    >
    > > #include <stdio.h>
    > > int main(int argc, char *argv[]) { char *v[] = { NULL };
    > > execve(argv[1], v, NULL); }
    >
    > This is the linux glibc bootstrap code behaviour. main() is never
    > reached. It's not new either.
     
    erm.
    thanks for the descriptive information! -->

    (for linux ia32)
    can you provide more details on this? I'm not seeing this behaviour on
    glibc 2.1.3 and 2.2.4, and at least the code for 2.1.3 verifies this
    quite well (ignoring the __libc_start_main never going to happen argc + 1,
    integer overflow if you ever get argc to be fully controllable - not on linux
    at least.. might want to check other systems). glibc 2.2.x has changed
    the __libc_start_main code a bit (start.S for i386 looks the same), so
    i manually tried some code on a rh 7.2 box - which doesnt
    have startup code crashes you talk about. From my tests, it passes control
    into main from __libc_start_main ok.
    there is some debugging output which uses argv[0] in __libc_start_main,
    but this can be ignored.

    is this linux your talking about, or some other system? i have not
    been able to reproduce the behaviour you describe, but i do not know the
    code that well, and only am using linux ia32.

    > > This is of course, not really a security threat by any means.. It is an
    > > annoying bug that effects alot of things and is really not handled
    > > correctly in the majority of implementations.
    >
    > How about not misusing exec()? 'course not, let's patch our kernels to
    > stop idiots from using exec()!!

    i think maybe a kernel patch is the best place for this.. its not fantastic
    I agree, but is probably the best solution. Do the single unix specs or
    something have anything to say of what is standard behaviour here? - ie,
    kernel or user space problem.

    BUT..

    if you really know what your talking about.. can you actually say what
    versions its effecting.. because i cannot see which version of
    glibc code your talking about here! and "glibc bootstrap code".. seriously,
    what does that mean? i'm really only thinking of _start or __libc_start_main
    at this point, unless your refering to some sort of whack rtld issue, or
    kernel -> rtld issue, which i dont see is going happen. lets not even
    get into code that doesnt link against libc

    *sigh*

    --
    Silvio
    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.netsys.com/full-disclosure-charter.html