>So by "buffer overflows" are you asking about the classic "stack
>overflow, corrupt the RP value" type overflows exclusively or are more
>simpler "unanticipated input" file reading/executing type acceptable
>too?

YES

:-)

I think the input validation problems common to form inputs that feed into
interpreted CGI scripts, etc. deserves its own thread. I now mainly wanted
to focus on the types of issues that lead to heap/stack/buffer (memory)
overflow vulnerabilities and how to ferret them out in a white box (source
code analysis) and black box (pen test) sense. A form input feeding into a
compiled CGI script would be something included this area as well.

Essentially, I think white-box testing for these types of vulnerabilities
for web applications is not much different than for current operating system
applications. Having the source code makes the job inherently easier almost
all of the time, but the black box testing methodology has a slightly
different angle. I'm interested in anyone's experience with manual and
automated black-box/pen-test methodologies for "remotely" stepping through
and assessing a web application's exposure to buffer overflows.

-dave

-----Original Message-----
From: Marc Matteo [mailto:marcmlectroid.net]
Sent: Monday, March 25, 2002 11:49 AM
To: dendlerowasp.org
Cc: webappsecsecurityfocus.com
Subject: Re: OWASP How to Test for Input Buffer Overflows?

On Mon, 2002-03-25 at 06:02, David Endler wrote:
> A good point
> was brought out earlier in the black box/white box discussions that just a
> source code analysis may not necessarily discover all aspects of buffer
> overflow issues, depending how much the app relies on the infrastucture
for
> input processing.

Can we get an operational definition of "buffer overflow"? :) As I said
before, to me a buffer overflow is a "smashing the stack for fun and
profit" type of thing and maybe because I work more in interpreted
languages than compiled ones (for web work) I don't see "buffer
overflows" as a major threat.

I see "unanticipated input" as a threat. :)

As an example, I was just recently asked to look at a commercial, Perl
based, web app. Now you could run tools like RATS against it all day
and never find a seemingly harmless call to the main admin subroutine at
the end of a simple command subroutine.

Harmless, of course, until you realized that it was a one line mistake
that gave the whole frigging world access to the main admin section if
the user called the simple command directly (which, of course, was
"unanticipated" - oops).

So by "buffer overflows" are you asking about the classic "stack
overflow, corrupt the RP value" type overflows exclusively or are more
simpler "unanticipated input" file reading/executing type acceptable
too?

> What about other languages, any known lists or well written published
unsafe
> coding practices available out there?

My favorites:
Perl CGI: http://phrack.org/show.php?p=55&a=7
PHP: http://www.securereality.com.au/studyinscarlet.txt

Cheers,
Marc

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