Mailing-List: contact docs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: docs@httpd.apache.org
From: "Chris Paget" <chris.paget@defcom.com>
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>,
	<security@apache.org>,
	<docs@httpd.apache.org>
Subject: RE: Service Account on Win32 [was part 1;
 Three problems with  Apache 2.0.35 under Win32]
Date: Fri, 19 Apr 2002 10:48:31 +0100
Message-ID: <AHENIKBNIMMOFIFIGJOEKEOBCCAA.chris.paget@defcom.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <5.1.0.14.2.20020416133618.025a4620@pop3.rowe-clan.net>
Importance: Normal

William,

My comments are inline below.  Apologies if it's a bit long-winded...

> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: 17 April 2002 20:44
> To: security@apache.org; docs@httpd.apache.org; chris.paget@defcom.com
> Subject: Re: Service Account on Win32 [was part 1; Three problems with
> Apache 2.0.35 under Win32]
>
> >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.

What you are saying does indeed make sense, however I was thinking along
slightly different lines.  Since the Apache installation requires
administrative rights on the machine to work, when "apache -k" is run, it
should also be running as the system administrator.  As such, the following
sequence should pose no problem:
1)  The MSI prompts the user for a security context for Apache.  This is
either Localsystem, an existing account, or a non-existant account.
2)  If Localsystem is chosen, a warning dialog is presented to the user
about the security implications, but they are allowed to continue.
3)  The account name is passed to the Apache -k installation - no password
is prompted for.
4)  Apacke -k checks to see if the account exists.  If it does not exist, it
is created (this is OK, since we are an administrator).
5)  Now that we know the account exists, apache -k chooses a completely
random password, and resets the password on that account to the chosen
value.
6)  The account name and new random password are passed to the SCM for
service installation.

Apache need never know what it's username and password are when it is
running, since the security context will be established by the SCM when the
service is started.  The account password will be unknown to everyone except
the SCM, but since the account will likely have less privileges than a
typical user (it need not, for example, be allowed to log on interactively),
this is not an issue.  The user should be warned that if they choose an
existing account under which to run Apache, the password will be reset; if
they really need to use that account to log on, then they can either take
the option of having Apache create its own account at install time, or
manually change both the account password and the password stored by the SCM
when the install is complete.  Additionally, if Apache creates it's own
account under which to run, all unneccessary privileges can be removed from
that account at install time; that way, users aren't left guessing what
privileges they can safely remove without breaking anything.  This is how
the IWAM_COMPUTERNAME account is handled by IIS for CGI execution, and
although the rest of the server is a bit of a sham, this part certainly
deserves merit.

Admittedly, you could theoretically attach a debugger to apache -k and
retrieve the password from somewhere within it's memory space, but to do
that you need to be an admin already...:)

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

Good philosophy.  However, since most Apache on Win32 users are likely to be
unix-heads looking to run something familiar on the MS platform, they are
likely to be unaware of what the different configurations are and how to
switch between them.  The scenario above provides them options without them
needing to learn how to administer the SCM.

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

IMHO, the installer asking the user if the service should be started
automatically at boot would be good, but that's another issue :)

> But this is best handled first as a documentation issue.

You're probably right there.

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

When I was testing this, I discussed this option with a seasoned
apache-on-unix administrator, and we came to exactly the same comclusion.
We agreed that the safest way to do it was to allow Apache no unneccessary
privileges at all, and not give it the option of running as localsystem at
any time.

Incidentally, Kerberos authentication within IIS 5 does allow for (some of)
this mechanism.  If a user account is granted the privilege of allowing
their account to be used for impersonation, when their ticket is passed to
IIS for authentication, IIS can re-use it securely in order to authenticate
to remote resources as that user; IIS effectively impersonates the user in
order to use their access rights to network resources.  I know it's only a
partial solution (and I have to admit I'm a little hazy on the details), but
it might be worth investigating nonetheless.

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

Agreed.  But in my experience security is better served when it is forced
upon a user to make a decision (and accept the default if need be), rather
than trusting that they will read the documentation and follow the
recommendations.  As a professional penetration tester, this is exemplified
perfectly by SP3 for SQL server; this warned the administrator that a blank
"sa" password (the default) was a major security risk, and prompted them to
change it.  After SP3 was released, we noticed a considerable downturn in
the number of vulnerable SQL servers.  The majority of blank sa passwords
that we come across now are due to systems being built around the low
security model, and there being considerable work involved in re-coding
things to accept a new password.  If that warning had been presented when
the SQL server was initially installed, there would not have been a problem.
I'm trying to avoid the same situation with Apache :)

Chris

--
Chris Paget
Security Consultant
Defcom Internet Security UK
chris.paget@defcom.com


---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org