You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brian Behlendorf <br...@hyperreal.com> on 1997/01/11 04:55:23 UTC
Might as well be a CERT warning.
Wonderful.
The question is, should we release a patch for 1.1.1? I think so, since
it looks like it'll be an easy fix.
COMMENTS PLEASE.
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@hyperreal.com http://www.apache.org http://www.organic.com/jobs
---------- Forwarded message ----------
Date: Fri, 10 Jan 1997 21:44:08 -0700 (MST)
From: Alfred Huger <ah...@secnet.com>
To: support@apache.org, root@apache.org, auscert@auscert.org.au
Subject: Apache and Apache derivitive Web Servers
To whom it may concern,
The following advisory is scheduled to be released early in the coming
week. Our date for release is scheduled for January 15th. The patch code
included with this advisory may be re-used in commercial or non-commercial
capacity as long as proper attribution is given.
Our release date is not set in stone. If anyone cc'd to this piece of mail
has difficulty with the proposed date, please let me know.
Note:
This advisory is for predistribution purposes. The actual release may
contain slight changes to grammar and spelling.
/*************************************************************************
Alfred Huger Phone: 403.262.9211
Secure Networks Inc. Fax: 403.262.9221
"Sit down before facts as a little child , be prepared to give up every
preconcieved notion, follow humbly wherever and whatever abysses nature
leads, or you will learn nothing" - Thomas H. Huxley
**************************************************************************/
###### ## ## ######
## ### ## ##
###### ## # ## ##
## ## ### ##
###### . ## ## . ######.
Secure Networks Inc.
Security Advisory
January 13, 1997
Vulnerabilities Apache httpd
There is a serious vulnerability in the cookies module of the Apache httpd,
version 1.1.1 and earlier, which makes it possible for remote individuals
to obtain access to systems running the Apache httpd. Only sites which
enabled mod_cookies, a non-default option, are vulnerable.
Technical Details
~~~~~~~~~~~~~~~~~
The function make_cookie, in mod_cookies.c uses a 100 byte buffer,
new_cookie to store information used to track web site users. The
hostname, which with even the most cautious of resolver libraries, can be
up to 255 characters long, is stuffed into this buffer, along with the
string "apache=" and a number. The offending code reads:
void make_cookie(request_rec *r)
{
struct timeval tv;
char new_cookie[100]; /* blurgh */
char *dot;
const char *rname = pstrdup(r->pool,
get_remote_host(r->connection, r->per_dir_config,
REMOTE_NAME));
struct timezone tz = { 0 , 0 };
if ((dot = strchr(rname,'.'))) *dot='\0'; /* First bit of hostname */
gettimeofday(&tv, &tz);
sprintf(new_cookie,"%s%s%d%ld%d; path=/",
COOKIE_NAME, rname,
(int)getpid(),
(long)tv.tv_sec, (int)tv.tv_usec/1000 );
table_set(r->headers_out,"Set-Cookie",new_cookie);
return;
}
Note that the get_remote_host() function converts all uppercase letters to
lowercase letters. Therefore, it is necessary to store code to call the
exec() system call someplace other than the hostname.
Impact
~~~~~~
Remote individuals can obtain access to the web server. If the httpd
services requests as the root user, attackers can obtain root access. If
the httpd is run in a chroot() environment, the attacker will be
restricted to the chrooted environment. We strongly advise adminstrators
to run their web servers as an unpriviliged users in an chrooted
environment whenever possible.
Vulnerable Systems
~~~~~~~~~~~~~~~~~~
Any system running the Apache httpd 1.1.1 or earlier, with the compile-time
option mod_cookies enabled is vulnerable. To tell which web server
software you are using, telnet to port 80 of the web server, and issue the
command:
GET / HTTP/1.0
to the web server, followed by two carriage returns. You should see
something which looks like:
$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.0
HTTP/1.0 200 OK
Date: Tue, 07 Jan 1997 18:59:31 GMT
Server: Apache/1.1.1
Content-type: text/html
Set-Cookie: Apache=localhost9185266357164; path=/
.
.
.
The important lines to look at are the Server: lines, and the Set-Cookie:
lines... The Server: line tells you which web server software you are
running, and the Set-Cookie line appears only if your web server is
using cookies to track users. If the Set-Cookie: line appears, and the
Server: line reads Apache/1.1.1, or a number smaller than 1.1.1, then you
are vulnerable.
Apache versions 1.2b0 and later do not appear to be vulnerable. This is
because as part of the changes made to the cookie handling code when it
was moved to mod_usertrack, the buffer in the make_cookie was moved out of
the stack. Therefore although the overflow is still present, and prevents
users with long host names from accessing the web server, it is not likely
to be exploitable.
In addition to the Apache httpd, some commercial web servers derived from
the Apache httpd are likely to be vulnerable. In particular, Thwate
Consulting's Sioux server, and Community ConneXion's Stronghold server
appear likely to be vulnerable. In both cases, as in the Apache httpd, a
nondefault compile-time option must be enabled. Exploitability of web
server software other than the Apache httpd has not been verified. Users
of Apache derived web servers should disable mod_cookies if enabled, and
contact their vendors for further information.
Fix Information
~~~~~~~~~~~~~~~
We suggest increasing the buffer length to handle 255 character hostnames,
and verifying that hostname length is within acceptable limits. Apply the
following diff, recompile, and then kill and restart your httpd in order
to fix Apache 1.1.1:
*** mod_cookies.c Tue Jan 7 14:38:15 1997
--- /usr/tmp/mod_cookies.c Tue Jan 7 14:38:11 1997
***************
*** 119,125 ****
void make_cookie(request_rec *r)
{
struct timeval tv;
! char new_cookie[100]; /* blurgh */
char *dot;
const char *rname = pstrdup(r->pool,
get_remote_host(r->connection, r->per_dir_config,
--- 119,125 ----
void make_cookie(request_rec *r)
{
struct timeval tv;
! char new_cookie[1024]; /* blurgh */
char *dot;
const char *rname = pstrdup(r->pool,
get_remote_host(r->connection, r->per_dir_config,
***************
*** 128,133 ****
--- 128,136 ----
struct timezone tz = { 0 , 0 };
if ((dot = strchr(rname,'.'))) *dot='\0'; /* First bit of hostname */
+ if (strlen (rname) > 255)
+ rname[256] = 0;
+
gettimeofday(&tv, &tz);
sprintf(new_cookie,"%s%s%d%ld%d; path=/",
COOKIE_NAME, rname,
Additional Information
~~~~~~~~~~~~~~~~~~~~~~
If you have any questions about this advisory, feel free to mail me at
davids@secnet.com. Past Secure Networks advisories can be found at
ftp://ftp.secnet.com/pub/advisories, and Secure Networks papers can be
found at ftp://ftp.secnet.com/pub/papers.
The following PGP key is for davids@secnet.com, should you wish to encrypt
any message traffic to me.:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAzJ4qJAAAAEEAOgB7mooQ6NgzcUSIehKUufGsyojutC7phVXZ+p8FnHLLZNB
BLQEtj5kmfww2A2pR29q4rgPeqEUOjWPlLNdSLby3NI8yKz1AQSQLHAwIDXt/lku
8QXClaV6pNIaQSN8cnyyvjH6TYF778yZhYz0mwLqW6dU5whHtP93ojDw1UhtAAUR
tCtEYXZpZCBTYWNlcmRvdGUgPGRhdmlkc0BzaWxlbmNlLnNlY25ldC5jb20+
=LtL9
-----END PGP PUBLIC KEY BLOCK-----
Many thanks to Ramsey Dow (ramseyd@secnet.com) for helping find vulnerable
Apache derivatives.
For further information about the Apache httpd, see http://www.apache.org
For further information about the Sioux web server, see
http://www.thawte.com/products/sioux
For further information about the Stronghold web server, see
http://stronghold.c2.net
Copyright Notice
~~~~~~~~~~~~~~~~
The contents of this advisory are Copyright (C) 1997 Secure Networks Inc,
and may be distributed freely provided that no fee is charged for
distribution, and that proper credit is given.
Apache httpd source code distributed in this advisory falls under the
following license:
Copyright (c) 1995, 1996 The Apache Group. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
3. All advertising materials mentioning features or use of this
software must display the following acknowledgment:
"This product includes software developed by the Apache Group
for use in the Apache HTTP server project
(http://www.apache.org/)."
4. The names "Apache Server" and "Apache Group" must not be used to
endorse or promote products derived from this software without
prior written permission.
5. Redistributions of any form whatsoever must retain the following
acknowledgment:
"This product includes software developed by the Apache Group
for use in the Apache HTTP server project
(http://www.apache.org/)."
THIS SOFTWARE IS PROVIDED BY THE APACHE GROUP ``AS IS'' AND ANY
EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE GROUP OR
ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
OF THE POSSIBILITY OF SUCH DAMAGE.
Re: Might as well be a CERT warning.
Posted by Marc Slemko <ma...@znep.com>.
On Fri, 10 Jan 1997, Brian Behlendorf wrote:
>
> Wonderful.
>
> The question is, should we release a patch for 1.1.1? I think so, since
> it looks like it'll be an easy fix.
>
> COMMENTS PLEASE.
Yup, release a patch; in fact, get a patch out now, linked to from
the main web page and ask him to add a pointer to the "official"
fix. Note that:
- I don't think it is the most serious hole in the code
- I am very doubtful about how easy (or possible) this is to
exploit because of several things, including what he mentions.
- I think there will be more holes found quite soon after
the release of this advisory, when people think to start
looking. It won't take long to find others.
The suggested patch looks fine, and isn't worth arguing about too
much since it will be fixed with snprintf.
> Fix Information
> ~~~~~~~~~~~~~~~
> We suggest increasing the buffer length to handle 255 character hostnames,
> and verifying that hostname length is within acceptable limits. Apply the
> following diff, recompile, and then kill and restart your httpd in order
> to fix Apache 1.1.1:
>
> *** mod_cookies.c Tue Jan 7 14:38:15 1997
> --- /usr/tmp/mod_cookies.c Tue Jan 7 14:38:11 1997
> ***************
> *** 119,125 ****
> void make_cookie(request_rec *r)
> {
> struct timeval tv;
> ! char new_cookie[100]; /* blurgh */
> char *dot;
> const char *rname = pstrdup(r->pool,
> get_remote_host(r->connection, r->per_dir_config,
> --- 119,125 ----
> void make_cookie(request_rec *r)
> {
> struct timeval tv;
> ! char new_cookie[1024]; /* blurgh */
> char *dot;
> const char *rname = pstrdup(r->pool,
> get_remote_host(r->connection, r->per_dir_config,
> ***************
> *** 128,133 ****
> --- 128,136 ----
> struct timezone tz = { 0 , 0 };
>
> if ((dot = strchr(rname,'.'))) *dot='\0'; /* First bit of hostname */
> + if (strlen (rname) > 255)
> + rname[256] = 0;
> +
> gettimeofday(&tv, &tz);
> sprintf(new_cookie,"%s%s%d%ld%d; path=/",
> COOKIE_NAME, rname,
Re: Might as well be a CERT warning.
Posted by Rob Hartill <ro...@imdb.com>.
On Fri, 10 Jan 1997, Brian Behlendorf wrote:
>
> Wonderful.
>
> The question is, should we release a patch for 1.1.1? I think so, since
> it looks like it'll be an easy fix.
>
> COMMENTS PLEASE.
On the bright side, it might make more people switch the
bloody thing off :-)
+1 on providing a patch and a 1.1.2 with it included.
Unfortunately, the people most likely to be at risk are the ones
who will miss the advisory and be ignorant of 1.2b