[12345] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Imagemap CGI overflow exploit

daemon@ATHENA.MIT.EDU (Thomas Reinke)
Tue Oct 26 15:51:14 1999

Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id:  <38150FBA.F4705681@e-softinc.com>
Date:         Mon, 25 Oct 1999 22:19:38 -0400
Reply-To: Thomas Reinke <reinke@E-SOFTINC.COM>
From: Thomas Reinke <reinke@E-SOFTINC.COM>
X-To:         John LoVerso <john@LOVERSO.SOUTHBOROUGH.MA.US>,
              bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM

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

home help back first fref pref prev next nref lref last post