Re: Imagemap CGI overflow exploit

From: Thomas Reinke (reinke@E-SOFTINC.COM)
Date: Mon Oct 25 1999 - 19:19:38 PDT

  • Next message: Julian Midgley: "RFP9905: Zeus webserver remote root compromise"

    John LoVerso wrote:
    >
    > > void main(int argc, char **argv)
    > > {
    > >         char      OutString[100];
    > >         // extract x & y from passed values
    > >         strcpy(OutString, argv[1]);
    > >
    > > This overflow can be avoided if you put the following code before
    > > strcpy().
    > >
    > > if (strlen(argv[1])>99) exit(0);
    >
    > While a tiny bounds check is usually important, IMHO it is more important to
    > notice the coding style.  The tiny snippet above tells me that the author of the
    > original code doesn't have much of a clue.  I don't mean just in regards to
    > static buffer sizes, but also in regards to effeciency, memory utilization, or
    > possibly even programming in C.  Why didn't they use "char *outstring =
    
    Whoa... Ok... then you can brand me with the same opinion. And I've
    spent 15 years on C and Unix, and won't even bother telling you what
    my credentials are other than that.
    
    The author made a single mistake - no bounds checking. There is nothing
    else there that is a mistake. Less than efficient, sure. Other ways
    of doing things? Sure. But you are making some dangerous judgements if
    you say that this reflects on
    
       a) the author's expertise
       b) the level of quality in a software package as a whole
       c) the security of the package
    
    > argv[1];"?  What do they do with Outstring, just pass it to atoi() to extract
    > x?  Or, perhaps, they even wrote their own version of atoi() with it's own
    > errors.  This code snippet has "I just learned C" all over it.  I wouldn't be
    > surprised if the original author didn't make dozens of similar mistakes.
    >
    > This is damning not only to this particular program, but also reflects on the
    > quality and care that went into "OmniHTTPd 1.01 and Pro2.04".  I don't know what
    > those programs are, but if they were commercial packages, this could be a
    > warning as to the possibility of their own weaknesses.  The willingness of an
    > author to ship such obviously broken code shows a distinct lack of
    > professionalism.  It's obvious they don't code review, which probably means they
    > couldn't have done a security review.
    
    You can't judge an author, and a software package by one line of
    code. There is more to software quality, security, and professionalism
    as a whole than your assessment implies.
    
    Perhaps I'm being overly blunt here, and I apologize if I'm somewhat
    out of line here, but there's much more to software quality, security
    and professionalism than what you would imply here, and certainly
    much more than can be assessed by a single line of code.
    
    >
    > I'm not trying to pick on one program or author, but this is indicative of the
    > state of software in general.
    >
    > This leads to one of the (usually) ignored keystones of that which, of late, has
    > aquired the name "open source software".  Having source doesn't just let you fix
    > or extend software upon which you depend.  Seeing the source code of a program
    > can give valuable insight about the quality and skill that went into it's
    > development.  Shunning code and products from sources of low quality can help
    > stem the tide of bugs, especially those that result in security vulnerabilities.
    >
    > John
    
    
    ------------------------------------------------------------
    Thomas Reinke                            Tel: (416) 460-7021
    Director of Technology                   Fax: (416) 598-2319
    E-Soft Inc.                         http://www.e-softinc.com
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:08:47 PDT