httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject summary of security issues
Date Sat, 04 Jan 1997 08:06:24 GMT
Below is a summary of what the remaining security issues before 1.2
are from my perspective.  Comments are needed on the last issue

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
		- possibly have mysnprintf just call snprintf if
		- 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.

View raw message