[2568] in WWW Security List Archive
Re: Security aspects of Microsoft FrontPage server extensions?
daemon@ATHENA.MIT.EDU (Scott Lystig Fritchie)
Thu Aug 8 16:15:22 1996
To: Prentiss Riddle <riddle@is.rice.edu>
cc: www-security@ns2.rutgers.edu
In-reply-to: Message of "Wed, 07 Aug 1996 16:18:45 CDT."
<199608072118.QAA14551@is.rice.edu>
Date: Thu, 08 Aug 1996 12:40:06 -0500
From: Scott Lystig Fritchie <fritchie@MR.Net>
Errors-To: owner-www-security@ns2.rutgers.edu
>>>>> 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. :-)
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.
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
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."
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.
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.
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.
YMMV.
-Scott
---
Scott Lystig Fritchie, Network Engineer MRNet Internet Services, Inc.
fritchie@mr.net, PGP key #152B8725 Minnesota Regional Network
v: 612/362.5820, p: 612/637.9547 2829 University Ave SE
http://www.mr.net/~fritchie/ Minneapolis, MN 55414
