Re: final versions of announce and security advisory

[Randy Terbush <ra...@covalent.net>]

Looks great Marc. Let me know when you are ready to fly and I will 
move the tarballs into place.

+1


> One last time before release, I would like to have feedback on the below
> (both the announce and security advisory are included)  and get the
> goahead to do the 1.2.5 release and send these out.  (seperately, with the
> **** draft copy**** bit removed of coures). 
> 
> Thanks to whoever pointed out that I can't count.
> 
> 
> ***************************************************************************
> ******************** DRAFT COPY -- DO NOT REDISTRIBUTE ********************
> ***************************************************************************
> 
> APACHE SECURITY ADVISORY
> Release Date: Tuesday, January 6 1998
> Topic: Possible security issues with Apache in some configurations
> 
> 
> Summary of Issues
> ============================================================
> 
> This advisory is to inform all Apache users of several possible
> security issues that have been discovered during an internal security
> review of the Apache source code.
> 
> DO NOT BE ALARMED BY THIS ADVISORY.  This is a pro-active step
> designed to be certain that users of Apache are advised of the
> issues and can take appropriate action to minimize their risk.
> 
> None of these holes allow for a root compromise (they only impact
> the user Apache runs as, as set with the "User" directive; if you
> have this user set to root, then fix your configuration now because
> you probably have a gaping security hole) and they generally
> require that a user already have access to the system before they
> can exploit them, meaning that on a large number of systems they
> are of little practical concern.  Some of the issues that have been
> addressed might not be exploitable in real-world conditions.
> 
> In some security environments, however, they may be of more concern.
> The administrator of the system running Apache is the only one who
> can make the judgment call as to how significant the below issues
> are in their environment.
> 
> Resolution of Problems
> ======================
> 
> We very strongly recommend that anyone using versions of Apache
> previous to 1.2 or earlier 1.2 versions upgrade to the newly released
> 1.2.5.  It is now available at
> 
> 	http://www.apache.org/dist/
> 
> There are no plans for an immediate 1.3b4 release to correct these
> problems in the 1.3 beta development tree, however we will make 
> patches for 1.3b3 to correct these issues available at 
> 
> 	http://www.apache.org/dist/patches/apply_to_1.3b3/
> 
> in the near future.
> 
> 
> Technical Description of Issues
> ===============================
> 
> Below is a step by step technical description of the potential
> problems discovered.  Read the below only if you wish to understand
> the details of the problems to better judge how they impact your
> server and if you have a solid grounding in how Apache works.  If
> in doubt, you are advised to simply upgrade to 1.2.5 as soon as
> practical.
> 
> 
> I.   Buffer overflow in cfg_getline()
> 
> 	RISK: medium
> 
> 	cfg_getline() is a function that the Apache core and several
> 	Apache modules use to read certain types of files from disk.
> 	Some examples of the type of files that read with this are
> 	htaccess, htpasswd and mod_imap files.
> 
> 	It is possible to create a sequence of data such that a
> 	buffer overflow occurs while cfg_getline is reading from
> 	a file.  If someone has access to create any of these types
> 	of files on the server, this hole is generally exploitable
> 	to gain full access to the user Apache runs as.
> 
> 	On most systems, this is of little consequence since users 
> 	already have such access via methods such as the creation of 
> 	their own CGI scripts.  If, however, the server is secured
> 	so that the user has no access to the server other than to
> 	create and modify files (eg. a "ftp only" account with no
> 	ability to create CGI scripts) this could allow increased
> 	access to the server.
> 
> 
> II.  Several coding errors in mod_include
> 
> 	RISK: medium
> 
> 	There are several coding problems in mod_include which can
> 	result in a buffer overflow or in the child process going
> 	into an infinite loop.
> 
> 	The same comments about the nature of the risk apply here as
> 	do for the cfg_getline() overflow.  Generally, a user already
> 	needs to have access to the server to exploit this.  Note that
> 	it is possible to setup a document which deliberately allows this
> 	to be remotely exploited, however such a document would be very
> 	rare in practice.
> 
> 	If you do not allow users to use mod_include, then they
> 	can not exploit these holes.
> 
> 
> III. Inefficient removal of duplicate '/'s ("beck" exploit)
> 
> 	RISK: medium
> 
> 	The code in the no2slash() function used to collapse multiple
> 	'/'s in a request for access checking purposes is very
> 	inefficient.  It is O(n^2) in the number of '/'s in the
> 	input.  What this means is that as the input size grows,
> 	it very quickly requires vastly increased CPU time to
> 	process the request.  By sending many requests with a large
> 	number of '/'s in to a server, it is possible to cause a
> 	large amount of CPU time to be used in processing these
> 	requests.  Making multiple simultaneous requests of this
> 	nature could result in a high load average, high CPU usage,
> 	and possibly starving other processes for CPU resulting in
> 	a denial of service attack.  This does not allow for any
> 	compromise of the server.
> 
> 	The fixed version of the no2slash() function is O(n) and
> 	does not allow for this attack.
> 
> 	Thanks to Michal Zalewski <lc...@boss.staszic.waw.pl> for
> 	discovering this bug and reporting it on the BUGTRAQ 
> 	mailing list along with the "beck" script that can be 
> 	used to exploit it.
> 
> 
> IV.  Possible buffer overflow in "logresolve" program.
> 	
> 	RISK: low
> 
> 	The logresolve program is used for non-realtime processing of
> 	logfiles to convert numeric IP addresses into host names.
> 	In some cases, it may be possible for a remote user who has
> 	control of a DNS server to return a hostname specifically 
> 	designed to exploit a coding hole in logresolve.
> 
> 	This can only happen on a system where either the MAXDNAME
> 	define does not exist and the resolver can return names
> 	longer than 256 characters or where the MAXDNAME define
> 	does exist but is less than the maximum length of hostname
> 	that the resolver can return.  Even on such (arguably
> 	broken) systems, this would be very difficult to exploit.
> 	The number of systems which are impacted by this is very
> 	small.  
> 
> 	This problem is a potential concern only if you use the 
> 	logresolve program.
> 
> 
> V.   Insufficient data validation in mod_proxy
> 
> 	RISK: low
> 
> 	The ftp proxy part of mod_proxy accepts directory listings
> 	from remote ftp servers and converts them to HTML to send
> 	to the client.  It is possible to deliberately create a 
> 	listing that will cause Apache to dump core.
> 
> 	This hole does not compromise the server; the only risk
> 	is that it would be possible to use this to create a 
> 	denial of service attack which would render the server
> 	effectively inoperative.
> 
> 	If you do not use mod_proxy, you are not vulnerable to this.
> 	If you restrict the use of mod_proxy, then only those users
> 	who are permitted to use it can attempt to exploit this
> 	problem.
> 
> 
> VI.  Possible buffer overflow reading from the proxy cache
> 
> 	RISK: low
> 
> 	When caching is enabled in mod_proxy, Apache writes cached
> 	files to disk as the user that the server runs as.  If an
> 	attacker can gain access to this user id (eg. by running
> 	a CGI script from a pre-existing account on the machine)
> 	then they can modify the filenames on disk resulting in a
> 	buffer overflow.  
> 
> 	Because the data is limited to what can be stored in a
> 	filename (not the file, just the filename), and they already
> 	need to have access to the user ID the server runs as to
> 	exploit this, the risk is minimal.
> 
> 	The main instance where this may be a cause for concern is if
> 	there is privileged information stored in memory by the 
> 	web server, such as an unencrypted SSL key.  This same
> 	caution, however, applies to the other buffer overflows
> 	listed.
> 
> 	If you do not use mod_proxy, this problem can not be
> 	exploited.
> 
> 
> VII. Unreadable htaccess files were ignored
> 
> 	RISK: low
> 
> 	Previously, if a htaccess file was unreadable Apache ignored
> 	it.  This is, from a security standpoint, a poor idea
> 	because it goes against the principle of "if in doubt, deny
> 	access".  This had already been corrected in the 1.3
> 	development tree, but we had refrained from making the
> 	change in 1.2 because it could cause unexpected behavior
> 	on existing sites.  We have since reconsidered, and as of
> 	1.2.5, Apache will now reject requests if there is a htaccess
> 	file present in the relevant directory tree that is unreadable
> 	for any reason.
> 
> 	It is also possible, in very rare conditions, for this to
> 	to be used to bypass htaccess files restricting access to
> 	a directory or file.  The only case where this can happen
> 	is if the attacker can form a request that results in the
> 	full path to the htaccess file being too long (on most
> 	systems, meaning over 1024 characters) yet the request for
> 	the protected file in the same directory is not too long.
> 	The only normal case where such an attack could be possible
> 	is if there is a symbolic link such as "somedir -> ."
> 	created in the document tree.
> 
> 
> Contact Information
> ===================
> 
> Full information about Apache and the 1.2.5 release which fixes
> these issues is available at http://www.apache.org/
> 
> Normal bugs can be reported via http://www.apache.org/bug_report.html
> 
> If you believe you have discovered a security hole in Apache, please
> be sure to contact us at security@apache.org so that we can verify
> and resolve the problem.  Support questions to this address will
> not get a response.  We fully support the concept of full disclosure,
> however it is always preferable to try to work with the vendor
> first before publicizing information about security holes.
> 
> ***************************************************************************
> ******************** DRAFT COPY -- DO NOT REDISTRIBUTE ********************
> ***************************************************************************
> 
> 
> ----------
> 
> Apache 1.2.5 Released
> ---------------------
> 
> The Apache Group is pleased to announce the release of the
> latest version of the Apache web server, version 1.2.5.
> 
> This is a bugfix release containing minimal changes from 
> the previous version, 1.2.4.  The main changes are a number of 
> fixes for possible security issues that have been discovered during
> a security review of the Apache source code.  While this release
> was being prepared, an additional denial of service attack was
> reported by a user.  A patch for this is also included.
> 
> This is a pro-active release designed to help ensure that users of
> Apache can be confident in the ongoing security of their webserver.
> Full details of the security fixes are available in the separate
> security advisory, available at http://www.apache.org/XXXXX
> 
> Apache has been the most popular web server on the Internet since
> April of 1996.  The January 1998 WWW server site survey by Netcraft
> (see:  http://www.netcraft.co.uk/Survey/) found that more web
> servers are using Apache than all other software combined; Apache
> and its derivatives are run on over 50% of all web domains on the
> Internet.
> 
> Included below is a summary of changes between 1.2.4 and 1.2.5, as it 
> appears in the CHANGES file in the "src" subdirectory in the release.  
> 
> 
> Changes with Apache 1.2.5
> 
>   *) SECURITY: Fix a possible buffer overflow in logresolve.  This is
>      only an issue on systems without a MAXDNAME define or where 
>      the resolver returns domain names longer than MAXDNAME.  [Marc Slemko]
> 
>   *) Fix an improper length in an ap_snprintf call in proxy_date_canon().
>      [Marc Slemko]
> 
>   *) Fix core dump in the ftp proxy when reading incorrectly formatted
>      directory listings.  [Marc Slemko]
> 
>   *) SECURITY: Fix possible minor buffer overflow in the proxy cache.
>      [Marc Slemko]
> 
>   *) SECURITY: Eliminate possible buffer overflow in cfg_getline, which
>      is used to read various types of files such as htaccess and 
>      htpasswd files.  [Marc Slemko]
> 
>   *) SECURITY: Ensure that the buffer returned by ht_time is always
>      properly null terminated.  [Marc Slemko]
> 
>   *) SECURITY: General mod_include cleanup, including fixing several
>      possible buffer overflows and a possible infinite loop.  This cleanup
>      was done against 1.3 code and then backported to 1.2, the result
>      is a large difference (due to indentation cleanup in 1.3 code).
>      Users interested in seeing a smaller set of relevant differences
>      should consider comparing against src/modules/standard/mod_include.c
>      from the 1.3b3 release.  Non-indentation changes to mod_include
>      between 1.2 and 1.3 were minimal.  [Dean Gaudet, Marc Slemko]
> 
>   *) SECURITY: Numerous changes to mod_imap in a general cleanup
>      including fixing a possible buffer overflow.  This cleanup also
>      was done with 1.3 code as a basis, see the the previous note
>      about mod_include.  [Dean Gaudet]
> 
>   *) SECURITY: If a htaccess file can not be read due to bad 
>      permissions, deny access to the directory with a HTTP_FORBIDDEN.  
>      The previous behavior was to ignore the htaccess file if it could not
>      be read.  This change may make some setups with unreadable
>      htaccess files stop working.  PR#817  [Marc Slemko]
> 
>   *) SECURITY: no2slash() was O(n^2) in the length of the input.  
>      Make it O(n).  This inefficiency could be used to mount a denial 
>      of service attack against the Apache server.  Thanks to 
>      Michal Zalewski <lc...@boss.staszic.waw.pl> for reporting
>      this.  [Dean Gaudet]
> 
>   *) mod_include used uninitialized data for some uses of && and ||.
>      [Brian Slesinsky <bs...@wired.com>] PR#1139
> 
>   *) mod_imap should decline all non-GET methods.
>      [Jay Bloodworth <ja...@pathways.sde.state.sc.us>]
> 
>   *) suexec.c wouldn't build without -DLOG_EXEC. [Jason A. Dour]
> 
>   *) mod_userdir was modifying r->finfo in cases where it wasn't setting
>      r->filename.  Since those two are meant to be in sync with each other
>      this is a bug.  ["Paul B. Henson" <he...@intranet.csupomona.edu>]
> 
>   *) mod_include did not properly handle all possible redirects from sub-
>      requests.  [Ken Coar]
> 
>   *) Inetd mode (which is buggy) uses timeouts without having setup the
>      jmpbuffer. [Dean Gaudet] PR#1064
> 
>   *) Work around problem under Linux where a child will start looping
>      reporting a select error over and over.
>      [Rick Franchuk <ri...@transpect.net>] PR#1107
>