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! :-)
... 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.
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, <blizzard@nysternet.org>, has also made his comments about security problems with FrontPage available also.
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.
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 <riddle@is.rice.edu>
cc: www-security@ns2.rutgers.edu
Subject: Re: Security aspects of Microsoft FrontPage server extensions?
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>
Message-Id: <199608081740.MAA20598@data.mr.net>
>>>>> 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.
[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
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