httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@gonzo.ben.algroup.co.uk>
Subject Re: WWW Form Bug Report: "Usr of ".map." in file name causes problems" on HPUX (fwd)
Date Sat, 29 Jun 1996 21:51:04 GMT
Randy Terbush wrote:
> 
> > On Sat, 29 Jun 1996, Randy Terbush wrote:
> > 
> > >
> > > I'm skeptical about whether this magic number check can be done
> > > efficiently enough to make it worthwhile.
> > >
> > > My feeling is that if you feed mod_imap binary data, you lose.
> > >
> > > Would it be rediculous to just trap SIGSEGV here and log an error?
> > >
> > 
> > In my personal opinion (and professional programming opinion) I would
> > disagree with that method.  Number One, it's messy (signals almost
> > always are--especially cross-platform).  Number Two, SIGSEGVs are caused
> > by programming errors that should not be there.  You never want to
> > allow memory to be overwritten.  Think of it this way; remember all
> > of the holes that have been found where the problem was allowing a
> > memory overflow?  Can we name a few programs?  Hrm.. I think fingerd was
> > one of them at one time; and Sun recently had to fix syslogd because they
> > had an overflow problem.
> > 
> > Overflows are *BAD* ideas.  I certainly wouldn't want one of my customers
> > trying to gain unauthorized access to my system because he/she was able
> > to overflow a memory buffer and happen to get unwanted code executed.  Sure,
> > it could take forever and a day for someone to do it; but it has been done
> > in the past.
> > 
> > Michael Douglass
> 
> Agreed. I guess I was under the naive assumption that a signal was
> identifiying something that was _going_ to happen, not something that
> _has_ happened.

The point is that you can overflow a buffer without causing a signal ... it all
depends how much you overflow and what into...

> 
> Another possible solution to this problem would be to establish an 
> "Apache format" imagemap that requires an identifying header. We could
> then declare other formats to be a security risk and supply a simple
> script that would update the NCSA format files.

Even if it had the correct header it could still have contents which overflow
the buffer. The thing to do is to not overflow the buffer...

Cheers,

Ben.

> 
> ??
> 
> 
> 
> 

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.

Mime
View raw message