Message-ID: <20031112225336.GG98840@sentex.net>
From: damian at sentex.net (Damian Gerow)
Subject: Frontpage Extensions Remote Command Execution

Thus spake Paul Schmehl (pauls@...allas.edu) [12/11/03 17:21]:
> You're serious?   I mean *really* serious?  Or is this a test?

Really, *really* serious.

> How do you explain this, for example?
> 
> http://httpd.apache.org/docs/misc/security_tips.html

What do I need to explain?

There's nothing in that document that says, 'After installing apache, unless
you do this simple task, you are open to a vulnerability.'

At its worst, it says, 'Because Apache runs as a specific user, and thus all
configured sites run as that user, these users can potentially attack each
other.'

(In fact, there has been a vulnerability released in the past year (six
months?) that has let people do exactly that.  So that is the only real
point of concern.)

However, let's look at the installation.

I use FreeBSD.  So I install the www/apache13 (or www/apache13-modssl) port.
It installs, doesn't enable SSI, has suEXEC configured in it by default,
runs as a non-root user, and has pretty sane restrictions on what it can and
cannot serve.  As well, www/apache13 already has 'AllowOverride None' on /.

So I don't have to worry about SSI stuff, but CGI stuff is still a concern.
But I already have suEXEC enabled, so I just need to attach the users (yes,
this is a bit of a concern, I agree), and I've already attained 90% of the
'To run a really tight ship, do ...' the document specifies.

Let's take this a step further.

I want webmail.  So I install the www/horde port.  And look at that -- it
*also* installs with sane restrictions, so that people can't view my
documents or configuration files.

So I really do fail to see what I need to explain.  I still stand by what I
said, that a decent OS shouldn't need the admin to go in afterwards and
modify filesystem permissions in order to guarantee a base line of
security.*

The biggest problem I see here is that there is no example for suEXEC in the
configuration file.  And Apache could perhaps enable suEXEC by default for
/~jschmoe URLs (or does it -- I don't know).

The other big concern is the installation of www/mod_php4, www/mod_perl, and
the like.  Not under suEXEC, you are pretty much open to do what you want as
the web server.  That includes potentially killing any of the children httpd
processes.

Under suEXEC, you are open to do what you want as the user.  That does *not*
include killing any httpd processes.

However, this is considerably more complicated than a, 'this file should not
have been installed with such loose permissions' problem.  This is a
continuing, ongoing configuration problem, not a one-time fixup due to a
problem in the install.

So to get this up and running with a base line of security, I did *not* have
to once go in and change the permissions on any of the files that the port
installed.

It's entirely possible that I have missed something glaringly obvious (that
happens when you focus on multiple things at once), so please, point it out
to me if I have.

  - Damian

* = In reviewing my comment, I should also state this: While this came as a
direct result of a Microsoft-ism, this also applies to any other platform.
OS X has had its own filesystem permission problems (OS X Server, I'm not
sure about), and I'm sure that somewhere in the history of Open Source there
have been security issues with default permissions.  Not to mention Solaris,
AIX, Irix, AUX...

Powered by blists - more mailing lists