httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: Service Account on Win32 [was part 1; Three problems with Apache 2.0.35 under Win32]
Date Wed, 17 Apr 2002 20:18:32 GMT
[Sorry if this is a dup... forgot this mailer likes commas and not semicolons]


   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
>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 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
>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\" ==
> ), 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 
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 
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 
to the account must be stored somewhere, and I'm terribly uncomfortable, no 
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 
a safe mechanism for CGI execution.

So feel free, on this first issue you raised, to address it to the world 
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 mailing list.  Your continued 
of new potential vulnerabilities are welcomed at

Thank you again for your comments, more posts (to the appropriate lists) to 


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message