httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Murcko <>
Subject security-info-digest V2 #402 (fwd) (long)
Date Sat, 31 Aug 1996 19:41:59 GMT
This astonished me enough that I thought the group might like a look at
it. Apologies to any who've already seen it.

> security-info-digest       Friday, 30 August 1996       Volume 02 : Number 402
> From: Michael Mathieu <>
> Date: Fri, 30 Aug 1996 12:41:24 -0700
> Subject: RE: Security aspects of Microsoft FrontPage server extensions? 
> To: "''" <>
> I'm Mike Mathieu, the Group Program Manager for the Vermeer Technologies
> group at Microsoft.  I'm responsible for the design of FrontPage.  As of
> this morning I'm on this mailing list, so this will be my only apology
> for a tardy response to this initial posting.
> I think it's important to be clear about the issues here.  There are
> some well documented web server security issues that people should be
> aware of, that Scott's posting reiterated and expanded upon.  It's
> important for people to know about.  There are other areas where there's
> obviously some misunderstanding about how FrontPage actually works and
> integrates with web servers, so I'd like to clear those up.
> See mm> comments below.
> Thanks,
> - -Mike
> >----------
> >From: 	Scott Lystig Fritchie[SMTP:fritchie@MR.Net]
> >Sent: 	Thursday, August 08, 1996 10:40 AM
> >To: 	Prentiss Riddle
> >Cc:
> >Subject: 	Re: Security aspects of Microsoft FrontPage server extensions? 
> >
> >>>>>> On Wed, 7 Aug 1996 16:18:45 -0500 (CDT), Prentiss Riddle
> >>>>>><> said:
> >
> >pr> Background: MS FrontPage is a Windows-based WYSIWYG HTML editor.
> >pr> For optimum use of FrontPage, users are instructed to ask their
> >pr> ISPs to install the FrontPage "server extensions", [...]
> >
> >Translated from marketing-speak, that means: really big CGI
> >executables.  :-)
> mm> The goal of FrontPage is to make it so easy for average people to
> publish their own webs that the market for web hosting services is going
> to explode.  End users want features.  They want to do things with their
> webs.  HTML by itself isn't as interesting as what you can do with real
> code.  Thus, the server extensions.  There's no apologies about the fact
> that we have code running on the server.  That's a big benefit.  What's
> interesting to you, I think, is how to minimize the space required for
> this code.
> mm> On UNIX we require 5 meg of server extensions per web.  On a typical
> system we'll take 5meg per *server*, through the use of UNIX hard links.
>  Also, if you put /usr/local/frontpage on the same partition as the
> content, then there is *no extra space* per server because, again, we
> use hard links.
> mm> For ISPs running virtual servers, we've got a special kit that you
> can get direct from Microsoft for free.  It lets you maintain
> independent security settings per virtual server, while only requiring
> about 50k per user (rather than the 5meg).  Check out
> >Well ... here are the things that I don't like about the FrontPage
> >extensions, are potential security problems, or both.
> mm> I'll focus on the security issues, rather than personal dislikes of
> design issues, given the nature of this list.
> >
> >1. FrontPage requires installation in /usr/local/frontpage.  Your only
> >other option is to create a symlink from /usr/local/frontpage to
> >someplace else.
> >
> mm> As Scott points out, you can put the kit anywhere you want.  You
> just create a symbolic link to it.  Three other options we discussed
> >during development but rejected are:
> >
> >1. Rely on an environment variable (pain to set up, not passed on to CGI
> >programs by some web servers)
> >2. Take a command line arg (not an option for CGI programs)
> >3. Search in a number of locations instead of just one (slower, more to
> >document).
> mm> I'd be interested in anyone with particular comments on this design
> choice replying back to me.  If there's a good reason, it's something we
> >can change in the future.
> >
> >2. FrontPage must have write permission to your server's configuration
> >files, to /usr/local/frontpage, and "... if possible, the HTTP server
> >process itself (to send a SIGHUP restart signal)."  The FrontPage user
> >account must also own all of the files in the server's document root.
> mm> This is an unfortunate step needed to overcome limitations in CERN,
> NCSA, and Apache servers (it's not an issue with Netscape or Microsoft.)
> > To help address this, we worked with Ready-to-Run Software to create a patch
> >to Apache so that this is not required.
> >
> >3. By default, files uploaded via FrontPage are apparently
> >world-writable.  I can probably fix that with a wrapper or something
> >around Apache's startup to change the umask, but it's annoying.
> >
> >mm> We view this as a feature.  We write them with full permission.  This
> gives you complete flexibility in how you configure your web server.  As
> >Scott notes, you can fix this by changing the server's umask.  If we turned
> >off world-write access then there would be no way for you to turn it back on.
> >
> >4. The "tar" file the extensions come in will extract all the
> >executables, their directories, etc. world-writable.
> >mm> Scott's right. We shouldn't do this.  However, you can easily fix it:
> >
> >	cd /usr/local/frontpage; chmod -R o-w .
> mm> I will make sure that this gets fixed.
> >
> >5. FrontPage transfers data using the content type
> >"application/x-vermeer-encoding" (or something like that).  A MS FP
> >tech support guy mentioned something in passing that that data is
> >encrypted "pretty strongly".  Though I haven't been listening much, I
> >haven't heard if MS has published the algorithm used.  Sounds like
> >encryption via obfuscation, but I could be wrong.
> mm> I'm not sure who you talked to about this in our Product Support
> Services, but we should be very clear on this point.  There is no strong
> encryption here.  It's not plain text that's passed in, but it's not far
> off.  We have some exciting new work coming up in this area but nothing
> I can talk about right now.  Stay tuned to the Microsoft web site.
> >6. "FrontPage cannot restart servers that support 'preforking'".
> >
> >mm> This is similar to 2.  In those cases where we modify the server's config
> >file we also have to restart the server to get it to read the modified config
> >file.  Again, this is not a problem with Netscape or our patched Apache
> >server.  And, again, this only affects a very few operations (create web,
> >rename web).
> >
> >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.
> >     
> >CLUE!?!  "Not necessarily a good idea" is understated, IMHO.  Why
> >bother suggesting it?  Why not put in a section saying, "You're one
> >sorry SOB if you run your server under the superuser's uid.  Don't
> >even try it."
> mm> You are right.  Running as root is a bad idea.  We do say it's a bad
> idea.  We say that the best scheme is to run as the user.  I hear your
> concern that people without a certain level of technical sophistication
> might be confused here.
> >8. Here's the "Security Issues" section.  I'll quote it in its
> >entirety.  All the talk about "If you run the HTTP server as root" is
> >astonishing.  Does the Win95 documentation for using the "Briefcase"
> >for portable PCs mention anything about "If you're using your portable
> >PC while falling from the roof of the Empire State Building, ..."
> >
> mm> Point taken.  Security implies tradeoffs.  e.g. between level of
> >security and cost.  Our goal in this section of the docs is to describe all
> the tradeoffs and let the webmaster/server admin decide how they want to
> do it.
> mm> I'd be interested in hearing comments from people if they think that
> our install instructions assume too much knowledge on the part of the
> webmaster/server admin.  We were trying to strike the right balance
> between giving enough information and not being condescending.  If you
> think we need to go further in one direction or another, I'd be
> >interested in hearing about that.
> >
> >I've got a few more comments after this long-ish section.
> >
> >    * FrontPage allows the users to upload executable CGI scripts.  If you
> >run
> >      the HTTP server as root and allow the server's CGI scripts to run as
> >root,
> >      authors can upload arbitrary executables and shell scripts which can be
> >      run with root privileges.
> >    
> >      Prevention:
> >       - Turn off the ability to save to executable CGI scripts with the
> >         NoExecutableCgiUploads server configuration parameter.
> >       - Do not configure the HTTP server (with User/UserId) to run as root
> >    
> >    * If you run the HTTP server as root, and if you allow FrontPage users
> >      to upload arbitrary CGI scripts, users can eventually get root
> >privileges.
> >    
> >      Prevention:
> >       - Turn off the ability to save to executable CGI scripts with the
> >         NoExecutableCgiUploads server configuration parameter.
> >       - Protect the HTTP server's configuration files and configuration file
> >         directory so that the CGI user has no write access.  Note: You'll
> >have
> >         to temporarily make the configuration files and directory writable
> >         when you want to use FrontPage to create new webs.
> >
> >    * Authors can upload arbitrary shell scripts which can affect all webs
> >under
> >      your HTTP server.
> >    
> >      Prevention:
> >       - Turn off the ability to save to executable CGI scripts
> >    
> >    * If you run the HTTP server as root, and you choose an insecure umask
> >      (one with world write access or one with group write access where some
> >      users are members of the group), users can replace FrontPage Server
> >      Extensions with arbitrary shell scripts executables that will be run
> >      with root privileges.
> >    
> >      Prevention:
> >       - Choose and set a secure umask before installing the executables
> >         and running the HTTP server.
> >    
> >    * FrontPage's Save Results Bot can allow the user to save form results
> >into
> >      a file named by a file path.  If you run the HTTP server as root,
> >      and allow the server's CGI scripts to run as root, authors can set up a
> >form
> >      where the results are written to an arbitrary file in the file system.
> >    
> >      Prevention:
> >       - Do not configure the HTTP server (with User/UserId) to run as root.
> >       - Turn off the ability to save to file system paths in the Save
> >Results Bot
> >    
> >    * FrontPage's Save Result Bots can allow the user to pipe form results
> >into
> >      an arbitrary program.  This allows security holes identical to those
> >      described above.
> >    
> >      Prevention:
> >       - Do not configure the HTTP server (with User/UserId) to run as root.
> >       - Protect the HTTP server's configuration files and configuration file
> >         directory so that the CGI user has no write access.  Note: You'll
> >have
> >         to temporarily make the configuration files and directory writable
> >         when you want to use FrontPage to create new webs.
> >       - Turn off the ability to pipe the Save Results Bot output to
> >programs.
> >       - Specify a restricted list of programs with the
> >SaveResultsPipeToAllows
> >         server configuration parameter.
> > 
> >9.  FP doesn't deal well with aliases to directories outside of the
> >web server's document root.  The one exception to this are "personal
> >webs", using the server's "~" notation for accessing individual user's
> >home directories (or subdir thereof).  If you want to use FP on those
> >"personal webs", the recommended steps are:
> >
> >   - Before installing FrontPage into a user's web, change the owner/group
> >     of all the per-user web's files to the FrontPage user/group.  Also,
> >     change the file access permissions to be compatible with the HTTP
> >     server's umask.
> >    
> >   - Change the /etc/group file so that each user is in the FrontPage
> >     group.  Use a group-inclusive umask for the HTTP server.  Then, change
> >     the group and access modes of the user's per-user web directories and
> >     files so that they are writable by their group and so that their group
> >     is the FrontPage group.  Note however, that using this scheme will
> >     allow these users to modify any files in any other web under the HTTP
> >     server from their UNIX login.
> >
> >10.  FP does indeed support "multihoming" or multiple virtual servers
> >on a single machine.  There are some catches, though:
> >
> >	1.  You must use the same frontpage userid for all
> >	FP-enabled virtual servers.  If there are exploitable bugs
> >	in the FP CGI programs, you could have a party modifying the
> >	content of any other FP-enabled virtual server.  [There's
> >	probably a way around this problem, but I'm so sick of dealing
> >	with FP at the moment that it will wait until later.]
> >
> >	2. If you're using Apache and using the <VirtualHost> command,
> >	a "properly" configured FP machine means that any FP-enabled
> >	virtual server can modify the config file you're using for all
> >	of that machine's virtual servers.
> >
> >Several of these things could be fixed by doing some things like not
> >necessarily following MS's installation instructions to the letter.
> >Another would be to put your HTTP server in a chroot()'ed environment.
> >Raise your hands if you think this is a pain in the !@#$!.
> >
> >The approach I took was to break up my <VirtualHost> server config
> >file into separate config files, using the BindAddress command, for
> >each virtual server.  So, instead of having one Apache process + its
> >preforked children, I have one Apache process + its preforked children
> >for each virtual server.  It's a waste of resources, but at this point
> >I really don't trust the FP stuff not to have bugs which could really
> >muck up service for the other virtual servers on the machine.
> >
> mm> Scott, I admire your industriousness here.;-)  This is indeed a
> laborious task, and fortunately for everyone, we've created a special
> kit just for ISPs or other people running into this situation.  This is
> available free just for the asking (email  We
> distributed this in hard copy form to several hundred ISPs at ISPCON the
> first week of August.
> mm> The kit includes more complete technical details of FrontPage, a
> section on Unix security and config, and a Primer on web hosting with
> FrontPage (taking an ISP angle on the topic).  It also includes the
> Apache patch source code I talked about earlier, and provides Perl
> scripts you can use to customize your own installation.  If there are
> issues that aren't addressed in the kit, then I'd be very interested in
> hearing about them.  We think we've addressed all of the important
> issues with this kit, but we're always looking for more feedback to
> improve things.
> mm> You can also check out
> It contains some technical info for hosting webs with FrontPage, and
> will soon be updated with the information and sample files from the WPP
> >kit I mention above.
> >
Chuck Murcko	N2K Inc.	Wayne PA
And now, on a lighter note:
Parker's Law:
	Beauty is only skin deep, but ugly goes clean to the bone.

View raw message