You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@znep.com> on 1998/01/06 21:59:22 UTC
final versions of announce and security advisory
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
Re: final versions of announce and security advisory
Posted by Dean Gaudet <dg...@arctic.org>.
Looks good +1 on all fronts.
Dean
On Tue, 6 Jan 1998, Marc Slemko wrote:
> 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.