Microsoft FrontPage server extensions file permissions problems

Date: Fri, 9 Jan 1998 14:52:52 -0800
From: Dave Pifke <dave@VICTIM.COM>
To: BUGTRAQ@NETSPACE.ORG
Subject: Password problem in FrontPage 98

The Microsoft FrontPage server extensions store their configuration files
underneath the document root for the web server.  In a multi-user
configuration (i.e. an ISP), this is typically the public_html
subdirectory of a user's home.

One of the directories it creates for configuration information is
'_vti_pvt', in which it creates a file 'service.pwd' containing
username:cryptpw, one line per user.

_vti_pvt is created 0775 and service.pwd is created 0664.  Removing
group-write or world-read permissions breaks the extensions (you can no
longer log in).

The world-read setting is bad (let's hope most users don't use the same
login password as they do for FrontPage, sigh), and the group-write is
even worse (again I point to the typical ISP setup).  Since the cgi-bin
programs execute setuid to the user the extensions belong to, there is no
reason for them to be set this way.  I have a feeling Microsoft is simply
sloppy in their use of open() flags.  (they had a problem with needing
httpd.conf to be world-writable(!) that just recently got fixed)

I don't know the other implications of having _vti_pvt (and the other
config files it contains) group-writable.  Because the software is setuid,
it is quite possible that there's a way to compromise the accounts of
anyone using FrontPage.

This was tested against the latest version (3.0.2.1117) on an Apache
server under Solaris.

Basic understanding of UNIX file permissions should be a prerequisite to
shoving software down ISPs' throats.


--
Dave Pifke, dave@victim.com

From root@VICTIM.COM Mon Feb 16 00:49:29 1998
Date: Fri, 9 Jan 1998 17:05:21 -0800
From: hostmaster 
To: BUGTRAQ@NETSPACE.ORG
Subject: Addendum to FrontPage password issue

Upon further review, the problem is not as severe as I originally thought.

Everything is set umask 002 only if a group is specified on the fp_install
command line (i.e. you don't want everything owned by group root).  And
they're world-readable because the web server (presumably running as
nobody) has to be able to read them to do HTTP authentication.

The permissions _can_ be succesfully changed.  In my case, I used a
Solaris ACL to give the httpd user read permission and set the password
files to 0600, and changed the umask in the fp_install script to be a
little less trusting. YMMV - changing the permissions made it bomb the
first time around, but its working for me now.

Sorry for the false alarm.  There are still some very strange things going
on with the default installation scripts' use of permissions and I intend
to review this more thoroughly over the weekend.


--
Dave Pifke, dave@victim.com