httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject cvs commit: apache-site/info security_bulletin_1.2.5.html index.html
Date Tue, 06 Jan 1998 22:10:50 GMT
marc        98/01/06 14:10:50

  Modified:    info     index.html
  Added:       info     security_bulletin_1.2.5.html
  Add the security advisory to the tree.
  Revision  Changes    Path
  1.3       +4 -0      apache-site/info/index.html
  Index: index.html
  RCS file: /export/home/cvs/apache-site/info/index.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- index.html	1997/11/26 17:59:10	1.2
  +++ index.html	1998/01/06 22:10:49	1.3
  @@ -17,6 +17,10 @@
     Web server development project.
  +   <DT><A HREF="security_bulletin_1.2.5.html">Security Advisory</A> </DT>
  +   <DD>A security advisory discussing possible security issues in Apache 
  +       versions before 1.2.5, including 1.3 beta versions up to 
  +       and including 1.3b3.</DD>
      <DT><A HREF="apache_books.html">Apache Books</A></DT>
      <DD>A list of books written about the Apache Web server.</DD>
      <DT><A HREF="aol-http.html">AOL and HTTP/1.1</A></DT>
  1.1                  apache-site/info/security_bulletin_1.2.5.html
  Index: security_bulletin_1.2.5.html
  <TITLE>Apache Security Advisory</TITLE>
  <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  <H1 ALIGN="CENTER">Apache Security Advisory</H1>
  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
  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
  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
  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 &lt;; 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
  	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
  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
  	If you do not use mod_proxy, this problem can not be
  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 -&gt; ."
  	created in the document tree.
  Contact Information
  Full information about Apache and the 1.2.5 release which fixes
  these issues is available at
  Normal bugs can be reported via
  If you believe you have discovered a security hole in Apache, please
  be sure to contact us at 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.

View raw message