Microsoft FrontPage server extensions file permissions problems
|Description:||Abhorrent permissions are required for some files related to the Microsoft FrontPage server extensions. For example _vti_pvt is a 775 directory which contains mode 664 service.pwd that contains the crypt()ed passwords for users.|
|Author:||Dave Pifke <dave@VICTIM.COM>|
|Compromise:||Not only can local users find out (or sometimes change) the passwords used for web accounts, but determing these passwords may lead to compromise of more important accounts that may use the same passwords.|
|Vulnerable Systems:||Those running Microsoft FrontPage server extensions 188.8.131.527 under UNIX |
|Date:||9 January 1998 |
Date: Fri, 9 Jan 1998 14:52:52 -0800
From: Dave Pifke <dave@VICTIM.COM>
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 (184.108.40.2067) on an Apache
server under Solaris.
Basic understanding of UNIX file permissions should be a prerequisite to
shoving software down ISPs' throats.
Dave Pifke, email@example.com
From root@VICTIM.COM Mon Feb 16 00:49:29 1998
Date: Fri, 9 Jan 1998 17:05:21 -0800
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, firstname.lastname@example.org
The master index of all exploits is available
here (Very large file)
Or you can pick your favorite operating system:
This page is part of Fyodor's exploit
For a free program to automate scanning your network for vulnerable
hosts and services, check out my network mapping tool, nmap. Or try these Insecure.Org resouces:
[ Nmap |
Sec Tools |
Mailing Lists |
Site News |