[2859] in WWW Security List Archive
RE: Security aspects of Microsoft FrontPage server extensions?
daemon@ATHENA.MIT.EDU (Michael Mathieu)
Fri Aug 30 18:28:47 1996
From: Michael Mathieu <mikemat@microsoft.com>
To: "'www-security@ns2.rutgers.edu'" <www-security@ns2.rutgers.edu>
Date: Fri, 30 Aug 1996 12:41:24 -0700
Errors-To: owner-www-security@ns2.rutgers.edu
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: www-security@ns2.rutgers.edu
>Subject: Re: Security aspects of Microsoft FrontPage server extensions?
>
>>>>>> On Wed, 7 Aug 1996 16:18:45 -0500 (CDT), Prentiss Riddle
>>>>>><riddle@is.rice.edu> 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
http://www.microsoft.com/frontpage/ispinfo.
>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.
>
>Um, er, HELLO! DO THE DOC WRITERS HAVE ANYTHING REMOTELY RESEMBLING A
>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 fptech@microsoft.com). 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 http://www.microsoft.com/frontpage/ispinfo.
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.
>
