httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: summary of security issues
Date Sat, 04 Jan 1997 09:25:48 GMT
I wonder if we could "point" to an snprintf implementation, like the glibc
one, maybe tweaked a bit.  So if it fails say ... you can #define it to
sprintf or you can get this snprintf that is covered by the gnu library
license.

Maintaining an snprintf shouldn't be much harder than the bprintf we've
already got... should it?

symlinked log files is equally an issue with things like syslog, yet
there's no compelling movement to fix that in some way... Given the talk
recently in BUGTRAQ maybe we can just lift someone else's solution.  It's
a pain to get right across architectures though.  We might get further by
writing a "securing your apache server" FAQ.  We should mention things
like the log files, a restrictive <Directory />, symlinks in document
trees, dns attacks. 

Dean

On Sat, 4 Jan 1997, Marc Slemko wrote:

> Below is a summary of what the remaining security issues before 1.2
> are from my perspective.  Comments are needed on the last issue
> especially.
> 
> symlinked log files: no easy and comprehensive solutions for
> 	preventing apache from overwriting files by symlinking from
> 	the log file.  Apache could check to see if the logfile is a
> 	link before opening it, which would reduce the risk since then
> 	someone would need to exploit a race condition or be able to
> 	do a hard link.  Are there people actually using symlinks for
> 	logfiles in normal use that this would break things for?  The
> 	conclusion seems to be to document this problem and that's
> 	good enough, at least for now.  If this is not done magically
> 	before I get some time, I will add it to where I think it
> 	would be appropriate in the docs and send in a diff.  The
> 	problem with the symlinked lock file in /tmp has already
> 	been fixed.
> 
> suexec: currently is dangerously broken WRT userdir executions and
> 	must not be released as is.  Discussion is ongoing.  Some
> 	changes are tenatively planned, but I think more are needed.  
> 
> buffer overflows: there are a number of overflows that are known to be
> 	potential trouble makers, some that are known to be harmless,
> 	and a whole lot that are in the middle.  Not everyone is happy
> 	with my suggested fixes as is, for some valid reasons (ie.
> 	magic numbers in sprintfs are bad especially when we are
> 	practically at a release).  I would be happier if they could
> 	be converted to a snprintf type thing; the one from the
> 	libraries with xinetd has been suggested and looks workable,
> 	however it introduces more possibly broken code, and likely
> 	code that won't compile some places.
> 
> 	A possible procedure:
> 		- replace sprintf calls with mysnprintf or whatever
> 		- make the xinetd snprintf equiv. compile as
> 		  mysnprintf.
> 		- possibly have mysnprintf just call snprintf if
> 		  available.
> 		- large note in the docs, "if mysnprintf don't
> 		  compile, do <foo> which will change a macro to use
> 		  sprintf instead then mail us why it wouldn't
> 		  compile"; it leave the security holes if they have
> 		  to use sprintf, but makes the thing compile with
> 		  a minimal effort.
> 
> 	I need to know how many people think they could support
> 	something like that, depending on how well it is implemented
> 	of course.  I am not going to spend my time right now
> 	playing with that idea if people don't want to take the
> 	risk.  It is not the ideal thing to be doing right before a
> 	release but not fixing them isn't ideal either.
> 
> 
> 


Mime
View raw message