Chris,
let me lead off by thanking you for evaluating Apache 2.0.35, with an eye to security. We take Apache's reputation for security very seriously. However, I have to take issue with having 'exposed' these problems. Two issues are documented [but that documentation can always be improved], while all issues mirror the behavior in Apache 1.3, IIRC.
I'll address only one issue per post so folks on the appropriate lists can tackle them separately. Let's start out with your first, and most difficult to address issue. I have copied the docs project, this isn't a undisclosed vulnerability, it is a documented behavior with obvious ramifications;
At 08:10 AM 4/16/2002, Chris Paget wrote to [EMAIL PROTECTED]:
Having just spent some time exploring the possibilities of Apache 2.0.35 running under Win32 (Windows 2000 Professional), I have exposed three problems with the default configuration. It is my opinion that if Apache is to truly succeed in overtaking IIS as the web server of choice on Win32, it must be more secure out-of-the-box than IIS (Patches aside). As such, I have 3 recommendations that you may wish to follow in order to enhance the security level of a default Apache/Win32 installation.
1) By default, the server is installed using LocalSystem account - High risk.
See http://httpd.apache.org/docs-2.0/platform/win_service.html under the section "User Account for Apache Service to Run As (NT/2000)". This is not an unknown issue, but a documented one. However, your comments are also helpful to some who aren't as familiar with the issues;
The Local System account posesses extremely high privileges on Win32. As such, running a daemon within this user context is very hazardous. Three specific problem with this configuration are: A: File permissions become largely irrelevant when the software is running as Localsystem. A single directory traversal attack against Apache on Win32 when running as LocalSystem would result in a total compromise of the machine. B: If a buffer overflow attack is discovered against Apache, then the privileges available to the exploit code are unlimited, and again a total compromise of the machine would result. C: If the configuration is changed such that a user may upload their own CGI's to the server (eg. to "My Documents\My Website\cgi-bin\" == www.server.com/~user/cgi-bin/ ), then a trivial privilege escalation attack would result unless the server context is changed. A user merely uploads their executable of choice into their cgi-bin folder and calls it through a web browser, whereupon it is executed with LocalSystem privileges.
I agree with your list of potential issues and encourage folks to modify the account to Run-As for security. However, on Windows or Unix, folks must take responsibility for configuring security and permissions. I agree we can call this out more prominently in the 'Getting Started' sections of the Windows platform docs [/docs-2.0/platform/windows.html].
But let me address your proposed 'solution' for a moment;
This issue is easy to fix, and (IMHO) should be changed in the default installation. The installation routine should prompt the Administrator for creation of a user- or even guest-level account (which will need to be granted the "Log on as a service" privilege), and those credentials should be passed to Win32 as the account to be used for the service. I have configured this manually on my installation, and the only change I needed to put in place was to ensure that the user chosen to run Apache has write-access to the Logs folder.
There are several-fold problems with this solution. First, we need to pass the password to the service control manager. One option is to accept an account name in the .msi setup, and pass the Apache -k install [or -k config] command a -u accountname flag {no such flag exists at present.} But we must prompt for the password to that account, in the setup. I refuse to pass passwords as command line arguments, since these are trivially snooped.
But unlike Microsoft, the Apache HTTP Project has an anathema to dictating what the "Proper Account Configuration" is for every user and application. Rather than trusting Microsoft's poor security judgement, we choose to make no judgement in machine configuration.
I would go so far as to have the installer not activate the service (leave it as
startup type "Manual") until the user reviews the configuration. But is that
practical for real world deployment? (It Doen't Work reports are not valuable
to open source projects.) I don't think so.
The biggest vulnerability, by far, is the addition of in-process or cgi-executed
scripts which are themselves insecure. And here again, the administrator
should make intelligent choices. I will work to introduce your desired changes
to let the user select an account to run-as in the installer, and perhaps introduce
a caution if they don't choose a -u accountname argument when installing or
reconfiguring the service. But this is best handled first as a documentation issue.
The correct solution would be to downgrade Apache's permissions after starting,
using configuration much like the PerChild experimental MPM for Linux. That
MPM for Apache 2.0.35/Linux (it has many issues at this moment) is designed
to allow each vhost to run in its own user context. This can be accomplished in
Windows, although it is a very different coding design. The only aspect that has
me hesitating for some time now, is that Win32 doesn't have a parallel to the
Unix setuid() construct. You can't simply impersonate any account. The password
to the account must be stored somewhere, and I'm terribly uncomfortable, no matter
what permissions are applied to the file, to ever storing that information in the
httpd.conf file. If that issue is resolved, we will be much closer to implementing
a safe mechanism for CGI execution.
So feel free, on this first issue you raised, to address it to the world community.
We do. We suggest the user choose a better account. While we have a much
smaller incidence of exploitable vulnerabilities than the 'other' Win32 HTTP
server solution, we aren't discounting the fact that new vulnerabilities are
discovered every day, and sometime in the future an Apache/Win32 vulnerability
could be discovered. Prudence makes sense, and we will work on our docs to
improve the user's understanding of the default behavior and recommended
security practices.
As an open source documentation project, your comments to that end are
welcome at the [email protected] mailing list. Your continued identification
of new potential vulnerabilities are welcomed at [EMAIL PROTECTED]
Thank you again for your comments, more posts (to the appropriate lists) to follow.
Bill
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
