httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory A Lundberg <>
Subject Re: general/2270: Required Patches to Apache sources for FrontPage Module (fwd)
Date Mon, 25 May 1998 07:25:04 GMT
On Sun, 24 May 1998, Dean Gaudet wrote:

> I highly encourage you, and/or others, to do this all cleanly from the
> ground up under a reasonable license... it would be VERY nice if stock
> apache supported frontpage cleanly (that doesn't mean we ship the module,
> it just means that if redhat provides you with an apache executable, you
> can LoadModule frontpage support, for example). 
> This is one of the goals I've put on a list I was making for "what do I
> want to see in apache?"  ... essentially I'd like it to be extremely easy
> for folks to set up servers which allow users to easily edit their
> websites.  That includes frontpage and PUT support.

Been thinking about this and wanted to share how I see support for
Frontpage should be done.  Dunno about general PUT support .. frankly that
makes me a tad nervous .. but maybe this will help with that too.

First, some review for those who don't know how Frontpage does its thing: 
Basically, it's just a CGI engine which allows storage and retrieval of
files on the web server.  There are three main programs: shtml.exe,
author.exe and admin.exe.  Recently, there've been a few special-purpose
CGI programs added for such things as hit counters, but they're just plain
old pre-compiled CGIs and no problem.

shtml.exe is intended to process SSIs in a Frontpage way.  It's not that
different from mod_include give or take.  Well, OK, it's mod_include on
steroids or 'Shhh.  I'm actually MS-PHP!'

author.exe is where the bulk of the action takes place.  It's main purpose
in life is to get and put double-documents: one html form-like beast which
describes the second.  The second is the html document being up/down
loaded.  It does a bit more, but it's mainly just getting and putting

admin.exe mainly just handles the .htacess files for the user.  It also
handles mod_auth basic-style htpasswd and group files.  Don't ask why all
this was coded into author.exe and this program is just a rename of that
file .. it's what MS wanted I guess.

Note that these Frontpage programs have nothing to do with the actual
security for Frontpage other than admin.exe's maintenance of the .htaccess
files (et al).  Frontpage's security model is based entirely on the
underlying server's: in this case Apache.

Now you have to understand that these three programs are BIG.  Web
administrators don't want to have copies laying in every user's directory. 
Not even considering the consequences of users being able to modify them
if they are in each directory; it's a monstrous waste of space.

We want to recognize requests for shared programs, in this case the
Frontpage modules, safely and transparently redirect them, and allow them
to be run as the web-page owner rather than the server.  This sounds like
a job for ScriptAlias and suEXEC.

In fact, ScriptAlias works fine except for one problem: suEXEC either
won't happen or, if it does, it'll make the wrong tests.  So what's needed
is a ScriptAlias-like beast that interfaces to something like suEXEC.  In
fact, this is all mod_frontpage and its supporting program does.  I'll
describe it, though, in what I see as the-way-it-should-be.  The steps
needed are: 

1) Chase down the URL through any rewrites and whatever else we want to
   happen until we have a reference to one of the documents (CGIs) we're
   interested in.  The idea is to behave as if the CGI actually exists in
   the user's directories right up to the point of executing it through

2) Don't stat() the files: they aren't there and if they are we don't want
   to use 'em anyway.  This is where mod_cgi gets in the way.  It wants to
   run the programs and they don't even exist.  mod_frontpage needed a way
   to stop this and do the execution itself.  This is the reason for that
   lame 'execfilename' variable.  Let's just toss it and give mod_cgi a
   new option telling it 'when you see a URI like this, just pass it off
   to something like suEXEC and don't bother checking it out'.

3) If the files actually had existed, we'd kick off to suEXEC at this
   point to run 'em.  Cool, but let's do it with a twist.  We need a
   modified suEXEC to handle the case of the target programs being
   somewhere else.

   a) verify the suEXEC-like program (I named it fpEXEC here, but if it's
      generalized a better name is needed .. I'll call it fpEXEC for now)
      exists in the expected spot and is properly installed and secure.
      Same as we'd do with suEXEC, just a different program.

   b) Pass off to fpEXEC instead of suEXEC.

   c) Like suEXEC, fpEXEC verifies the target program.  Frontpage's
      version takes the un-rewritten target and rewrites it now.  If this
      were a configuration option for suEXEC, we'd be able to use suEXEC.
      fpEXEC, however, knows the target directory and lookitthat the names
      are the same.  All we need to do it make sure the programs exist,
      are executable, owned by the right UID/GID, and securely installed.
      Just like suEXEC, but with a hard-coded (configurable?) set of IDs. 
      Of course, to be general, we'll want a rewriting rule configuration
      file for fpEXEC.  And, since we might get errors, like Frontpage's
      version, we'd like to die off with an html document rather than
      leaving the remote user hanging and logging 'premature end of script
      headers'.  Since Frontpage expects these responses, and wants them
      in a particular format, we'll need a configurable error-html script. 

   c) verify the target user.  But now we have a problem; no executable
      file to check.  We need something else.  For Frontpage, this is the
      file ~<user>/<webroot>/_vti_bin/service.cnf but we'd like it to be
      configurable to some other file in case this isn't Frontpage we're
      loading.  Maybe all we need to do is check the user's web directory
      itself, or the .htaccess file: is it owned by the ~<user>?  is it
      group- or world-writable?  Is its parent secure too?  All the same
      checks as suEXEC would make except the file doesn't need to be
      executable.  We'd like it to be something related to the CGI but I
      don't think that's an absolute requirement.

   d) Oh, and make sure we were run by the anonymous web-user and nobody
      else .. just like suEXEC.  BTW, here's a point where RtR went over-
      board.  They have mod_frontpage openning a secured file containing
      some random hashed values and piping it to their version of suEXEC.
      The idea is to not even trust the web administrator to have secured
      the machine properly: anyone can run the program so don't trust the
      UID .. instead since we're SUID-root let's open that root-only file
      and see if it matches what we're getting from the pipe.  Can anyone
      say 'handle depletion'?  A good idea, just not needed if you take
      the time to set up your server correctly.

   e) Proceed as suEXEC does to setgid(), setuid(), etc., and run the
      target program.

Alright!  If we've made the right modifications to Apache and mod_cfi, and
we've got a configurable suEXEC, we're ready to rock-n-roll.

Only one problem: this all depends upon having mod_auth, .htacess files,
group and user (htpasswd) files.  What happens if one of these isn't
there?  Why we let _anyone_ .. that's right .. anyone in the world .. have
at our nice Frontpage (or whatever) CGIs.  That sucks raw eggs at MACH 9
through a straw doesn't it?  All this work making things secure and some
dumb user FTPs in and DELEtes his .htaccess file blowing it all away.  So
we need one last change: we need to be ABSOLUTELY SURE _this_ URL was
approved through mod_auth with a valid .htaccess and a valid password
challenge and response. 

So, now to code it.  I've got quite a bit of it set to go.  I need to
parameterize my fpEXEC and tell mod_cgi to lay off (I do it now with a
hard-coded strncmp) and run something other than suEXEC (also currently
hardcoded) and I need to figure out how to be POSITIVE all the necessary
mod_auth checks have taken place on _this_ request before passing it off
to fpEXEC.

I am, of course, open to comments, suggestions, and help.


Gregory A Lundberg		Senior Partner, VRnet Company
1441 Elmdale Drive    
Kettering, OH 45409-1615 USA    1-800-809-2195

View raw message