Part of the FrontPage '98 Story

... and it's not pretty. See Microsoft FrontPage 98 Security Hell for an update on Microsoft's latest FrontPage offering and some of the known problems so far. How many more lurk within? Good question.

Why I Don't Like Microsoft's FrontPage Web Authoring Tool

I dislike it quite a bit, actually. I think its design leaves a lot to be desired, particularly when used on UNIX-based Web servers which host multiple virtual Web servers. Why, do you ask? Attached below is a message I sent to the <www-security@ns2.rutgers> mailing list a few days ago.

I've received several messages in response ... I'd be interested in hearing if you agree or disagree. Send me email at <fritchie@MR.Net>.

Chris Blizzard, <>, has also made his comments about security problems with FrontPage available also.

Read My Response to Microsoft FrontPage Program Manager!

After you've finished reading the my initial rant below, please read my response to Microsoft's FP program manager, Mike Mathieu. It, too, is long but points out a number of weaknesses in FrontPage 1.1. I haven't heard any further response from MS after sending this, so I can only hope that they've taken some of my advice to heart.

WARNING!If you do not wish to see a Bourne shell exploit of FP's biggest security hole, DO NOT READ THE END OF THE MESSAGE! :-)

To: Prentiss Riddle <>
Subject: Re: Security aspects of Microsoft FrontPage server extensions? 
In-reply-to: Message of "Wed, 07 Aug 1996 16:18:45 CDT."
Date: Thu, 08 Aug 1996 12:40:06 -0500
From: Scott Lystig Fritchie <fritchie@MR.Net>
Message-Id: <>

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

pr> Various people have recently reported security problems with the
pr> Microsoft FrontPage servers extensions.  A quick Alta Vista search
pr> of recent Usenet articles reveals claims like the following:

The FrontPage installation instructions from Microsoft were quite
humorous until I thought about the sysadmins out there who would take
them at face value.

pr> Does anyone know whether there are serious security problems with
pr> the Microsoft FrontPage servers extensions?  Or are problems like
pr> those that have been reported merely isolated cases of
pr> administrator error?

Well ... here are the things that I don't like about the FrontPage
extensions, are potential security problems, or both.

1. FrontPage requires installation in /usr/local/frontpage.  Your only
other option is to create a symlink from /usr/local/frontpage to
someplace else.

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.

[Not part of the original message, but added to help make the point
 clear to other readers:

 If all the content of virtual servers X, Y, and Z is owned by the
 FrontPage user/account, and there can be only one FrontPage
 user/account, and the virtual servers for X, Y, and Z are also running
 under the FrontPage userid, then the following undesirable things happen:

	1. A bug in the FrontPage server and/or client could be exploited
	   to allow an author of virtual server X to modify the content of 
	   virtual server Y.  This prospect is unlikely but possible;
	   abusers, if desperate, will take this route.  However, there's
	   something far easier to do, and that is...

	2. An administrator (and/or author?) of virtual server X can
	   upload an arbitrary CGI program to server X.  (In the
	   event that CGI uploading has been disabled via the FrontPage
	   extensions configuration file, other methods could be used,
	   including but not limited to FTP, Telnet, or exploiting a bug
	   (as in point #1 above) for virtual servers Y or Z (if CGI
	   uploading has not been disabled for those virtual servers)).

	   This CGI program could be malicious, e.g. edit or remove
	   any file it has permission to edit or remove.  Since all
	   of server Y's and Z's content is owned by the same userid
	   as server X's, X's malicious CGI program can edit at-will
	   any of Y's or Z's content.

 To quote myself, Scott Lystig Fritchie, "This is a Bad Thing(tm)."  In
 fact, it's shocking that MS claims that virtual servers are supported
 by FP.  Yes they are, but effective administrative barriers separating
 those virtual servers do not exist.  All it would take is one person with
 a grudge against the Department of Justice (to create a ficticious example)
 to get a FrontPage-enabled virtual server on the same machine the DOJ's
 FrontPage-enabled virtual server is on ... and edit DOJ's content: edit
 the home page, apply graffiti to graphic images, say disparaging things
 about the Attorney General, ....

 Hey, that sort of thing didn't happen recently, did it?  {shrug}

						-SLF, 8/26/96]

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.

4. The "tar" file the extensions come in will extract all the
executables, their directories, etc. world-writable.

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.

6. "FrontPage cannot restart servers that support 'preforking'".

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

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

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

Oh, one other thing.  I ran into hours of cussin' mad grief while
trying to use the expires-on-30-June-1996 beta/eval version of the FP
client.  DON'T USE IT.  Get a copy of the official release.


Scott Lystig Fritchie, Network Engineer          MRNet Internet Services, Inc., PGP key #152B8725               Minnesota Regional Network
v: 612/362.5820, p: 612/637.9547                 2829 University Ave SE                     Minneapolis, MN  55414