Date: Fri, 9 Jan 1998 14:52:52 -0800 From: Dave Pifke 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