OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Buffer Overflows and DoS
From: Crispin Cowan (crispinwirex.com)
Date: Thu Apr 27 2000 - 02:05:52 CDT

Douglas Ostling wrote:

> On Thu, 27 Apr 2000, Crispin Cowan wrote:
> > Douglas Ostling wrote:
> > > Of course, we know the DoS implications of this, so what is the
> > > result when the same happens to an application on an Openwall-patched
> > > kernel system?
> > Context dependent. The program might seg fault, or it might catch the
> > seg fault and carry on. Unlike StackGuarded programs, it does not
> > give you a definitive syslog entry that says "someone tried to
> > overflow this program in that function(), but I stopped them."
> In the case of lynx, I have seen the overflowed characters on the screen.

Seeing the characters on the screen is of no significance, other than it's
easier to read them :-)

> I have to kill the running program. This looks like the perfect candidate
> for StackGuard.

Yep. If you skoosh something, and StackGuard notices, it syslog's the event and
kills the process.

> How about the apache method of using a super-server to
> start the child processes? Could we do this with bind and sendmail, as well?
> Does this make better sense than inetd?

The inetd arrangement is just the general case of the apache arrangement. The
advantage to the inetd approach is that you don't have to care about the service
daemons for long. The downside is that fork/exec combos are slow, so you don't
get high bandwidth out of the inetd approach.

Crispin
-----
Crispin Cowan, CTO, WireX Communications, Inc. http://wirex.com
Free Hardened Linux Distribution: http://immunix.org
                  JOBS! http://immunix.org/jobs.html