httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <r...@imdb.com>
Subject INFO#98.444 - Apache Security Advisory (fwd)
Date Wed, 14 Jan 1998 23:37:28 GMT

I can't imagine any reason why to say no, so I'll respond with a yes
in a moment.


---------- Forwarded message ----------
Date: Wed, 14 Jan 1998 16:14:32 -0500 (EST)
From: "CERT(sm) Coordination Center" <cert@cert.org>
To: Apache folks <apache-bugs@apache.org>
Cc: "CERT(sm) Coordination Center" <cert@cert.org>
Subject: INFO#98.444 - Apache Security Advisory 

-----BEGIN PGP SIGNED MESSAGE-----

Hello Folks, 

We received a message from Marc Slemko about a recent Apache security
advisory. We believe this information deserves wide distribution and
would like to have your approval to "wrap" the text as a CERT
vendor-initiated bulletin. 

As you may already know, these bulletins are distributed the same way
as CERT advisories--we send them to the CERT mailing list (over 30K
addresses, some of which are mail exploders) and post them to the
comp.security.announce newsgroup.

I've included a sample of the 'wrapped' text at the end of this
message for your okay. We made one very minor change, a reformatting
of the text in one paragraph to move a "from" that occurred at the
beginning of a line (see Sec. V, 1st paragraph).

Can you let us know if this version is acceptable to you folks,
and if we have your approval to issue the VIB?   Once we have
the okay, we'll add the date and put it in the queue.

Many thanks in advance,
Georgia
==============================================================================
Georgia Killcrece

CERT* Coordination Center       | Telephone: +1-412-268-7090 24-hour hotline
Software Engineering Institute  | CERT Coordination Center personnel answer
Carnegie Mellon University      | business days 08:30-17:00 EST/EDT
Pittsburgh, PA 15213-3890       | (GMT-5)/(GMT-4), on call for emergencies
U.S.A.                          | during other hours.
Internet E-mail: cert@cert.org  | Fax: +1-412-268-6989
http://www.cert.org

*Registered in U.S. Patent and Trademark Office. 


The CERT Coordination Center is part of the Software Engineering
Institute (SEI).  The SEI is sponsored by the U.S. Department of Defense.


- -----BEGIN PGP SIGNED MESSAGE-----

=============================================================================
CERT* Vendor-Initiated Bulletin VB-98.01
xxxx xx, 1998

Topic:  Apache Security Advisory
Source: Marc Slemko, Apache Team Member <marc@apache.org>


To aid in the wide distribution of essential security information, the CERT
Coordination Center is forwarding the following information from Marc Slemko
of Apache. Apache urges you to act on this information as soon as
possible. Apache contact information is included in the forwarded text
below; please contact them if you have any questions or need further
information.


=======================FORWARDED TEXT STARTS HERE============================


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 <lcamtuf@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.


- - --
     Marc Slemko     | Apache team member
     marcs@znep.com  | marc@apache.org




========================FORWARDED TEXT ENDS HERE=============================

If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident Response
and Security Teams (FIRST). See http://www.first.org/team-info/.

We strongly urge you to encrypt any sensitive information you send by email.
The CERT Coordination Center can support a shared DES key and PGP. Contact
the CERT staff for more information.

Location of CERT PGP key
         ftp://ftp.cert.org/pub/CERT_PGP.key


CERT Contact Information
- - ------------------------
Email    cert@cert.org

Phone    +1 412-268-7090 (24-hour hotline)
                CERT personnel answer 8:30-5:00 p.m. EST
                (GMT-5)/EDT(GMT-4), and are on call for
                emergencies during other hours.

Fax      +1 412-268-6989

Postal address
        CERT Coordination Center
        Software Engineering Institute
        Carnegie Mellon University
        Pittsburgh PA 15213-3890
        USA

CERT publications, information about FIRST representatives, and other
security-related information are available from
        http://www.cert.org/
        ftp://ftp.cert.org/pub/

CERT advisories and bulletins are also posted on the USENET newsgroup
        comp.security.announce

To be added to our mailing list for CERT advisories and bulletins, send your
email address to
        cert-advisory-request@cert.org
In the subject line, type
        SUBSCRIBE  your-email-address



* Registered U.S. Patent and Trademark Office.

The CERT Coordination Center is part of the Software Engineering
Institute (SEI). The SEI is sponsored by the U. S. Department of Defense.


This file: ftp://ftp.cert.org/pub/cert_bulletins/VB-98.01.apache



- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNL0piHVP+x0t4w7BAQGd3AQA0Qqk8eZZWmqz+w4MVEgd01ZalT4J0bZl
wrOsJxCYDNsSvB13EGgzkDPbJbzdmqW4C6WAWyO2l7zQ2o8/OZPS9K9n1m7TI0TY
Ox3h9CVuN4CQgfMb0Z0NYdF9R47xFKyauljROJQGaW1M0ss0aU9jfZ16xiJhtEHE
PX24V0keyig=
=iSSn
- -----END PGP SIGNATURE-----


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBNL0qbnVP+x0t4w7BAQGbRgQAyVZPL2sB1XJZ+PBDnYKZjktVhWYKqjhd
q1pgmR+lqJajwsEptBf/89U82V+ijHVtce73dsRzcDS4neUdLY5SAjtkHzn6zeR2
lEyiHe2vB1Wavr5JBMbmCPp5doXkEKddYug7hxYZK4VFCvrXkVFg/dyr4Zq0g6fv
71iBWSx5McU=
=COoH
-----END PGP SIGNATURE-----


Mime
View raw message