OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: proton (protonENERGYMECH.NET)
Date: Mon Mar 05 2001 - 03:54:37 CST

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

    The overflow condition is *very* easily exploitable, since the
    code actually supplies the pointer to the exploit code itself,
    odd as it maye seem. The pointer thusly does not need to be
    second-guessed at all, making life much easier for crackers.

    Code excerpts;

    ...

    #define MAX_ENTRIES 10000

    typedef struct {
        char *name;
        char *val;
    } entry;

    ...

    main(int argc, char *argv[]) {
        entry entries[MAX_ENTRIES];

    ...

        for(x=0;cl && (!feof(stdin));x++) {
            m=x;
            entries[x].val = fmakeword(stdin,'&',&cl);
            plustospace(entries[x].val);
            unescape_url(entries[x].val);
            entries[x].name = makeword(entries[x].val,'=');
        }

    ...

    Fellow C programmers would surely see the problem right away.

    By feeding 10,000 bogus entries, and then sending a specially
    prepared buffer for the 10,001'th, you get a situation where
    memory is allocated, the exploit code is written into it and
    the pointer is then put into the 10,001'st position of the
    entries struct. This happens to be the position of the return
    pointer. When the program ends, it does not call `exit' as
    I would say most network applications should, instead it
    returns to __start, or in a case where the return pointer
    has been overwritten, it returns to the user-supplied code.

    The only problem with this exploit is that `fmakeword' allocates
    102400 bytes for each buffer. Before you think that the problem
    then becomes entirely theoretical, consider that most modern
    kernels does not give the programs actual physical memory until
    the memory is written to. A fair estimate would be that to be
    vulnerable the server would need around 40-50MB of physical
    and/or virtual memory, but I cant say for certain.

    To sum it up, this exploit is real, you may be vulnerable if you
    have the post-query CGI on your webservers (and it is *very* common).

    You may be lucky enough to have an OS that prohibits the application
    from successfully allocating the needed memory.

    Better safe than sorry; Remove the program if you have it!
    Noone should really need this type of application since it is a
    sample program designed to demonstrate how CGI works.

    I will post a working exploit to the bugtraq list in a while.

    /proton
    [ http://www.energymech.net/users/proton/ ]