AUSCERT#69716 -- Re: Apache and Apache derivitive Web Servers (fwd)

[Brian Behlendorf <br...@hyperreal.com>]

Cool, we did well.

	Brian


---------- Forwarded message ----------
Date: Mon, 13 Jan 1997 11:48:14 +1000
From: auscert@auscert.org.au
To: Alfred Huger <ah...@secnet.com>
Cc: auscert@auscert.org.au, support@apache.org, root@apache.org
Subject: AUSCERT#69716 -- Re: Apache and Apache derivitive Web Servers 

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

Content-Type: text/plain; charset=us-ascii


Hi 

Thanks for sending us a copy of this advisory you are planning on 
releasing.  I have assigned this the tracking number AUSCERT#69716.

The advisory looks pretty good.  I have made a couple of comments.
Sorry not to get it to you earlier, but I only got the email this
morning.

Take or ignore or comments as you see fit.

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

Something we find useful is to mark pre-release versions as DRAFT, and put
a date when last changed.  If it is clearly marked as DRAFT, people will
expect changes to occur between this and the final version.

You may also put a statement saying DO NOT DISTRIBUTE some where at the
top to make things clear that this is pre-distribution copy only.

> 
> 
> 
> /*************************************************************************
> 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.

You mention in the middle somewhere that other versions of the HTTP 
Daemon based on Apache may also be vulnerable (like Sioux and Community 
ConneXion's Stronghold server).  Our experience shows that people may 
not make it that far.  People may see that Apache is vulnerable, but
if they are not using Apache, will read no further as they think
they are not vulnerable.  However, if they are using an Apache based
web server, like Sioux, they may still have a problem.

It may be better to say something early that Apache based servers may 
also be vulnerable.

> 
> Technical Details
> ~~~~~~~~~~~~~~~~~

[snip]
 
> 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.

You may wish to mention that if an intruder gains root access in a chroot'ed 
area, there are ways to lever their way out, gaining root
privs on the entire system.  Restricting people to chroot'ed areas is
a good idea, but it will not stop the knowledgeable intruder once they
gain root privs.  

> 
> 
> 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

You probably are aware that the new version 1.1.2 has since been released.
You may wish to use this as a fix instead of your patch. I downloaded it 
and it has your patches applied.  It is good to see that apache moved
quickly on this problem.


[snip]


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

You could mention that the overflow problem will be fixed in the next
beta release of 1.2.  

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

As I mentioned above, you may wish to inform people at the top of 
the advisory that other web servers based on Apache may also be 
vulnerable and to contact there supplier.

> 
> 
> 
> 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:

As 1.1.2 has been released, you may wish to tell people to use that 
to remove the vulnerability.  You may also wish to give additional 
information of where they can get the new version (the canonical site
woiuld be sufficient):

	http://www.apache.org/dist/

If you have MD5 checksum information that may also be useful for the 
security minded.


[snip]


I hope this comments are useful and have not arrived to late for you
to consider.

Thanks again for sending us a draft copy of the advisory.  Once you
release your advisory, we will push it to our constituency allowing
them to protect themselves.  

Thanks also to the Apache people for working quickly to address this
problem.


- -- 
regards,
	tony

==========================================================================
 Anthony Shepherd                 |  Fax:    +61 7 3365 4477
 AUSCERT                          |  Phone:  +61 7 3365 4417
 c/- Prentice Centre              |  (answered during business hours)
 The University of Queensland     |  (on call after hours for emergencies)
 Qld.  4072.  Australia           |  Internet:  auscert@auscert.org.au



-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: ftp://ftp.auscert.org.au/pub/auscert/AUSCERT_PGP.key

iQCVAwUBMtog+yh9+71yA2DNAQE53gP+I3ixNXb6UIukCJSsuLEPQYqjtEHUQ8nZ
kdSBip4Y/vG7R6HHWfo6D3bj4T3GzoPwpkOA3MJ0X8xPSEPhwf6lucT/8i5mtpfE
fSqILm/9zLFXWv6rFb/pUFS+0JSBQKvLwOrlNEMosjJgL3aONS/C6fZjsuuBZ/KO
no6vv25kSj8=
=IWBc
-----END PGP SIGNATURE-----