User Root Frontpage Fun

[Mark J Cox <ma...@ukweb.com>]

I was digging around trying to find some reasons why Frontpage is a bad
idea and I came across this message sent to www-security about a year ago. 

I wonder how many web admins took the first option and added "User Root" 
to their config files?  I guess we'll find out when 1.3 is released and
it stops working :)

Mark

> Cc: www-security@ns2.rutgers.edu
> Subject: Re: Security aspects of Microsoft FrontPage server extensions? 
> Date: Thu, 08 Aug 1996 12:40:06 -0500
...
>7. Here's a quote straight from the version 1.1 installation
>instructions under the section "Restarting the Server":
>
>    2. The FrontPage Server Extensions run under the server as a CGI
>    program.  In order for the FrontPage Server Extensions to send the
>    restart signal to the HTTP server, the server's CGI programs must run
>    under the same user account as the HTTP server itself.  Your choices
>    are:
>     
>    - Run both HTTP server and CGI scripts as root.  In this case, the
>      UserId (if CERN) or User (if NCSA or Apache) field in your httpd.conf
>      file should be set to root, and you should launch the server as root.
>      This scheme is not necessarily a good idea however; for maximum UNIX
>      security, as few things as possible should run as root.  See "Security
>      Issues" below for more details.
>     
>    - Run both HTTP server and CGI scripts as the FrontPage user.  In this
>      case, the UserId and User fields are ignored.  This is the best
>      scheme, but it will not work if your server runs on a protected port.
     

Re: User Root Frontpage Fun

[Gary Wisniewski <ga...@spidereye.com.au>]

>I seem to recall Cliff and I coming up with a solution for front page...
>but I forget what it was because I forget what the heck front page wants
>root for.

FrontPage 1.1 wants root so it can restart httpd whenever it makes
changes to srm.conf on behalf of the FP user.

FrontPage 1.2 extensions no longer requires this providing you
hack up mod_alias.c to their specifications.

See my posting "FrontPage mod_alias fiddling" for some details about
how I worked-around all this.

Gary


------------------------------
Gary Wisniewski
Spider Eye Studios Pty. Ltd., Australia, +61 3 9415 6700
[Formerly GUI Online Productions]

Re: FrontPage mod_alias fiddling

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

At 12:45 PM 7/13/97 +1100, Gary Wisniewski wrote:
>It annoys me that Microsoft advises you to hack up your
>existing Apache directives, rather than simply adding a module
>themselves.  So, I actually created a module called
>	mod_fpalias.c
>which makes this legal:
>	FpScriptAlias */bin webuser
>
>Essentially, I cleaned-up Microsoft's hacks and put together
>a reasonable module which does the same thing. I don't like changing the
>meaning of existing directives.
>
>One of the *good* things about Microsoft's change is that,
>assuming you have it installed, FP no longer requires
>server restart (or Root privs) to have the extensions operate
>properly.  
>
>Would it be useful to create a doc page on FP extensions,
>and this sort of stuff, including mod_fpalias?

Definitely.  I'd be up for hosting the module in /dist/contrib, and having
a tutorial on "using FrontPage with Apache" on the apache web site; or if
hosted elsewhere, a semi-prominent link, say from related_projects.html.  

	Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
"Why not?" - TL           brian@organic.com - hyperreal.org - apache.org

Re: FrontPage mod_alias fiddling

[Dean Gaudet <dg...@arctic.org>]

On Sun, 13 Jul 1997, Gary Wisniewski wrote:
> 	ScriptAlias */bin

Isn't this the same as:

<Location ~ ".*/bin/">
    SetHandler cgi-script
    Options +ExecCGI
</Location>

?

I guess Microsoft just lets people put the cgis right into the document
hierarchy.  But should you want to move them around, Alexei's latest
AliasMatch stuff can be combined with the above.

> But also adds
> 	ScriptAlias */bin webuser

And this could be implemented by the above and adding a module that checks
the ownership of a file.  In fact, such a module could be a good place to
deal with all of the various SymLinksIfOwnerBlahBlah hacks we've had float
around. 

Dean

FrontPage mod_alias fiddling

[Gary Wisniewski <ga...@spidereye.com.au>]

Has anybody considered putting the FrontPage ScriptAlias
extensions into mod_alias.c?

Basically, when you get the newest FP extensions, it hacks
into the Apache sources during installation to allow things
like:
	ScriptAlias */bin
But also adds
	ScriptAlias */bin webuser

Essentially, in addition to adding the wildcards for ScriptAlias,
it also checks that cgi scripts are owned by "webuser" (or
any user, specifically) and refuses to run them otherwise.

It annoys me that Microsoft advises you to hack up your
existing Apache directives, rather than simply adding a module
themselves.  So, I actually created a module called
	mod_fpalias.c
which makes this legal:
	FpScriptAlias */bin webuser

Essentially, I cleaned-up Microsoft's hacks and put together
a reasonable module which does the same thing. I don't like changing the
meaning of existing directives.

One of the *good* things about Microsoft's change is that,
assuming you have it installed, FP no longer requires
server restart (or Root privs) to have the extensions operate
properly.  

Would it be useful to create a doc page on FP extensions,
and this sort of stuff, including mod_fpalias, or perhaps
a modified mod_alias which does what Microsoft wants?

Opinions?

Gary


------------------------------
Gary Wisniewski
Spider Eye Studios Pty. Ltd., Australia, +61 3 9415 6700
[Formerly GUI Online Productions]

Re: running server as root (Was: Re: PUT method)

[Ingo L�tkebohle <in...@blank.pages.de>]

Marc Slemko wrote:
> It is the case of many servers.  How many security holes has wu-ftpd has
> that let you get root?  How many secuirty holes has sendmail had that let
> you get root?  How many security holes has Apache had that let you get
> root?

That hit the spot, I'm afraid.
 
> I have gone through the source.  I have patched many security holes.  I am
> not convinced it is safe.

Ok, I'm convinced. Thanks for clearing that up.

---/dev/il

Re: running server as root (Was: Re: PUT method)

[Marc Slemko <ma...@worldgate.com>]

On Sat, 12 Jul 1997, Ingo L�tkebohle wrote:

> Marc Slemko wrote:
> > If you have a real uid of root, then if someone finds something like a
> > buffer overflow in the code that is exploitable they can get root.  Sure,
> > takes another couple of syscalls but no big deal.  That is not good.
> 
> Isn't that the case for almost every other server you care to mention?

It is the case of many servers.  How many security holes has wu-ftpd has
that let you get root?  How many secuirty holes has sendmail had that let
you get root?  How many security holes has Apache had that let you get
root?

The answer to the first two is lots, the last one is darn few, if any,
provided you have it configured correctly, even though correctly was not
always documented.  Note the first two run with a real uid of root some or
most of the time, the latter doesn't.

If Apache 1.1 ran with a ruid of root and just switched euids, it would
have almost certainly let someone get root through various bugs.

> What about switching to an EUID of nobody early in the request
> processing stage?

Does no good.  

There certainly are _lots_ of cool features that would be nice to do if
Apache could switch euid at will.  I am not yet convinced the security
risks are worth it.

I have gone through the source.  I have patched many security holes.  I am
not convinced it is safe.

Re: running server as root (Was: Re: PUT method)

[Ingo L�tkebohle <in...@blank.pages.de>]

Marc Slemko wrote:
> If you have a real uid of root, then if someone finds something like a
> buffer overflow in the code that is exploitable they can get root.  Sure,
> takes another couple of syscalls but no big deal.  That is not good.

Isn't that the case for almost every other server you care to mention?
What about switching to an EUID of nobody early in the request
processing stage?

---/dev/il

Re: running server as root (Was: Re: PUT method)

[Marc Slemko <ma...@worldgate.com>]

On Sun, 13 Jul 1997, Dean Gaudet wrote:

> Not to mention that if running as uid = 0 you can symlink and read any
> file on disk ... even after the patches in 1.2.1.  Consider race
> conditions.

Naw, no one is thinking of actually serving requests as root, but just
keeping a real or saved uid of root so we can swap around through other
users for different things.  There is actually a patch or two around to do
this and it lets you implement really cool features.  If only we were
Microsoft...

OTOH, the default configuration of a certain server which I won't name
(no, it isn't from MS or NS or any big company) runs all CGIs as root and
can make it quite challenging to change that.

> 
> Dean
> 
> On Sat, 12 Jul 1997, Marc Slemko wrote:
> 
> > On Sat, 12 Jul 1997, Ingo L�tkebohle wrote:
> > 
> > > Lars Eilebrecht wrote:
> > > > The better idea is IMHO to use
> > > > a kind of wrapper for this purpose, because running a web-server as
> > > > root is braindead, but hey we are talking about Microsoft. >;-)
> > > 
> > > Well... I guess I'm on unsafe ground here, but I am not so sure that
> > > running a server as root is an entirely bad idea. Of course, *serving*
> > > your typical anonymous request as root is a bad idea, but that does not
> > > mean that there are no good reasons to run a server as root (and switch
> > > UID's as needed).
> > 
> > If you have a real uid of root, then if someone finds something like a
> > buffer overflow in the code that is exploitable they can get root.  Sure,
> > takes another couple of syscalls but no big deal.  That is not good.
> > 
> > 
> 

Re: running server as root (Was: Re: PUT method)

[Dean Gaudet <dg...@arctic.org>]

Not to mention that if running as uid = 0 you can symlink and read any
file on disk ... even after the patches in 1.2.1.  Consider race
conditions.

Dean

On Sat, 12 Jul 1997, Marc Slemko wrote:

> On Sat, 12 Jul 1997, Ingo Lütkebohle wrote:
> 
> > Lars Eilebrecht wrote:
> > > The better idea is IMHO to use
> > > a kind of wrapper for this purpose, because running a web-server as
> > > root is braindead, but hey we are talking about Microsoft. >;-)
> > 
> > Well... I guess I'm on unsafe ground here, but I am not so sure that
> > running a server as root is an entirely bad idea. Of course, *serving*
> > your typical anonymous request as root is a bad idea, but that does not
> > mean that there are no good reasons to run a server as root (and switch
> > UID's as needed).
> 
> If you have a real uid of root, then if someone finds something like a
> buffer overflow in the code that is exploitable they can get root.  Sure,
> takes another couple of syscalls but no big deal.  That is not good.
> 
> 

Re: running server as root (Was: Re: PUT method)

[Marc Slemko <ma...@worldgate.com>]

On Sat, 12 Jul 1997, Ingo L�tkebohle wrote:

> Lars Eilebrecht wrote:
> > The better idea is IMHO to use
> > a kind of wrapper for this purpose, because running a web-server as
> > root is braindead, but hey we are talking about Microsoft. >;-)
> 
> Well... I guess I'm on unsafe ground here, but I am not so sure that
> running a server as root is an entirely bad idea. Of course, *serving*
> your typical anonymous request as root is a bad idea, but that does not
> mean that there are no good reasons to run a server as root (and switch
> UID's as needed).

If you have a real uid of root, then if someone finds something like a
buffer overflow in the code that is exploitable they can get root.  Sure,
takes another couple of syscalls but no big deal.  That is not good.

running server as root (Was: Re: PUT method)

[Ingo L�tkebohle <in...@blank.pages.de>]

Lars Eilebrecht wrote:
> The better idea is IMHO to use
> a kind of wrapper for this purpose, because running a web-server as
> root is braindead, but hey we are talking about Microsoft. >;-)

Well... I guess I'm on unsafe ground here, but I am not so sure that
running a server as root is an entirely bad idea. Of course, *serving*
your typical anonymous request as root is a bad idea, but that does not
mean that there are no good reasons to run a server as root (and switch
UID's as needed).

For example, the current abundance of authentication modules is an
administrative nightmare, not to speak of the fact that quite a few of
these modules are not stress-tested. The single most stated reason for
this is the fact that the HTTP protocol does transmit the password in
clear-text, which is a rather bad excuse as anyone familiar with other
protocols should admit. In my humble opinion, it creates more problems
than it solves.

I believe that a server with better integration into the UNIX security
scheme would be interesting at least. I am reluctant to go into more
detail here, to keep the mail from growing out of bounds, but I'll
gladly do so if there's interest. Of course, if there's no interest, I'm
silent ;-)

---/dev/il

Re: PUT method (was Re: User Root Frontpage Fun)

[Lars Eilebrecht <La...@unix-ag.org>]

According to Dean Gaudet:

> On Sat, 12 Jul 1997, Lars Eilebrecht wrote:
> 
> > On one of the servers I maintain I implemented PUT with a combination
> > of suexec, an old putscript (originally written for the cern httpd) and
> > mod_auth_sys. Well, it works (at least for PUT, not DELETE), but it's
> > somewhat awful, because I need to install a putscript-binary into
> > every users web-directory and need a <Directory> and <Files> section
> > for every user...
> 
> Can't you just use wildcarded or regex'd <Directory>/<Files> sections?

No, because authentication is a *good* idea when using PUT. ;-)
And the Script directive needs (AFAIK) an absolute url-path.

Example:

  <Files /usr/home/sfx/public_html/.put.cgi>
  require user sfx
  </Files>

  <Directory /usr/home/sfx/public_html>
  Script PUT /~sfx/.put.cgi
  </Directory>

ciao...
-- 
Lars Eilebrecht
sfx@unix-ag.org

Re: PUT method (was Re: User Root Frontpage Fun)

[Marc Slemko <ma...@worldgate.com>]

On Sun, 13 Jul 1997, Dean Gaudet wrote:

> On Sat, 12 Jul 1997, Lars Eilebrecht wrote:
> 
> > On one of the servers I maintain I implemented PUT with a combination
> > of suexec, an old putscript (originally written for the cern httpd) and
> > mod_auth_sys. Well, it works (at least for PUT, not DELETE), but it's
> > somewhat awful, because I need to install a putscript-binary into
> > every users web-directory and need a <Directory> and <Files> section
> > for every user...
> 
> Can't you just use wildcarded or regex'd <Directory>/<Files> sections?

With suexec you need the binary that is to be run as the user to be owned
by the user.  That means you need a seperate binary for each user.  That
means you need a seperate script for your Script directive.  That means ou
that means you need a seperate section; we would need something like:

<Directory /~(.*)/.*>
Script PUT /~$1/putscript.cgi
</Directory>

Re: PUT method (was Re: User Root Frontpage Fun)

[Dean Gaudet <dg...@arctic.org>]

On Sat, 12 Jul 1997, Lars Eilebrecht wrote:

> On one of the servers I maintain I implemented PUT with a combination
> of suexec, an old putscript (originally written for the cern httpd) and
> mod_auth_sys. Well, it works (at least for PUT, not DELETE), but it's
> somewhat awful, because I need to install a putscript-binary into
> every users web-directory and need a <Directory> and <Files> section
> for every user...

Can't you just use wildcarded or regex'd <Directory>/<Files> sections?

Dean

PUT method (was Re: User Root Frontpage Fun)

[Lars Eilebrecht <La...@unix-ag.org>]

According to Dean Gaudet:

> I seem to recall Cliff and I coming up with a solution for front page...
> but I forget what it was because I forget what the heck front page wants
> root for.

I've only used the FP extensions once... I installed them and after
20 Minutes uninstalled them and never used it again (the great about
the uninstall feature of the FP extensions is that it didn't worked
for me :-/).
But back to your question... I a user publishes a page to the server
the FP extensions need to write the page under the UID/UID of that
user. Therefore it needs to be root. The better idea is IMHO to use
a kind of wrapper for this purpose, because running a web-server as
root is braindead, but hey we are talking about Microsoft. >;-)

This problem will be arise when the PUT/DELETE methods are incorporated
into Apache (will they?).
BTW, there is a nice module called mod_put for this purpose,
but in most cases it's unusable because it can only write files
with the ID of the httpd process.

On one of the servers I maintain I implemented PUT with a combination
of suexec, an old putscript (originally written for the cern httpd) and
mod_auth_sys. Well, it works (at least for PUT, not DELETE), but it's
somewhat awful, because I need to install a putscript-binary into
every users web-directory and need a <Directory> and <Files> section
for every user...

I'm thinking about writing my own mod_put that does authentication itself
and passing the request to an external wrapper... but I haven't found the
time yet. Are there any other plans to add PUT/DELETE to Apache?

ciao...
-- 
Lars Eilebrecht
sfx@unix-ag.org

Re: User Root Frontpage Fun

[Dean Gaudet <dg...@arctic.org>]

Tee hee.  Er, 1.2.1 won't allow "User root" either.

I seem to recall Cliff and I coming up with a solution for front page...
but I forget what it was because I forget what the heck front page wants
root for.

Dean

On Fri, 11 Jul 1997, Mark J Cox wrote:

> I was digging around trying to find some reasons why Frontpage is a bad
> idea and I came across this message sent to www-security about a year ago. 
> 
> I wonder how many web admins took the first option and added "User Root" 
> to their config files?  I guess we'll find out when 1.3 is released and
> it stops working :)
> 
> Mark
> 
> > Cc: www-security@ns2.rutgers.edu
> > Subject: Re: Security aspects of Microsoft FrontPage server extensions? 
> > Date: Thu, 08 Aug 1996 12:40:06 -0500
> ...
> >7. Here's a quote straight from the version 1.1 installation
> >instructions under the section "Restarting the Server":
> >
> >    2. The FrontPage Server Extensions run under the server as a CGI
> >    program.  In order for the FrontPage Server Extensions to send the
> >    restart signal to the HTTP server, the server's CGI programs must run
> >    under the same user account as the HTTP server itself.  Your choices
> >    are:
> >     
> >    - Run both HTTP server and CGI scripts as root.  In this case, the
> >      UserId (if CERN) or User (if NCSA or Apache) field in your httpd.conf
> >      file should be set to root, and you should launch the server as root.
> >      This scheme is not necessarily a good idea however; for maximum UNIX
> >      security, as few things as possible should run as root.  See "Security
> >      Issues" below for more details.
> >     
> >    - Run both HTTP server and CGI scripts as the FrontPage user.  In this
> >      case, the UserId and User fields are ignored.  This is the best
> >      scheme, but it will not work if your server runs on a protected port.
>      
> 
> 
> 
> 
>