[Xitami] password in clear text

[Ewen McNeill]

In message <20011129041149.C2EC4B8101@christel.heitec.net>, Bernd Luevelsmeyer w
rites:
>on the Bugtraq mailing list, "Larry W. Cashdollar" raised the issue
>of Xitami storing the admin password in clear text in its default
>installation. 

While it is an issue (and has been in the FAQ for quite a while), the
situation that was discussed on Bugtraq (leading to a local root
exploit) requires:
- the plain text password file
- insecure permissions on the plain text password file
- an untrusted user with local access (web admin is local only by default)
- the webserver to be run as root

Having a plain text password in the file isn't ideal, but the combination
of untrusted local users, not checking the permissions on the file
containing the password, and running the server as root definitely don't
help either.

Xitami can be run as a non-root user (with a slight decrease in
functionality, or with the assistance of port redirection in the OS);
either started as root and have Xitami change to a non-root user (the
setuid functionality; but then the "restart" features in Xitami won't
work), or run on an off-numbered port (ie not port 80).  (If the OS
supports port redirection you can redirect port 80 to another one that
a normal user can bind to, and run Xitami on that port.)

The most direct step if you can't trust your local users is to change
the permissions on the password file to 0400 or 0600 (with the owner
being the user that runs Xitami), or to disable the web-based admin.
I typically do both on systems where I'm particularly concerned about
security.

>On FreeBSD the program won't run automatically after installation,
>but I'll provide more configuration help and safer defaults anyway.

Thanks for this, and thanks for your post to Bugtraq.  I do plan to
make my own post to Bugtraq -- but I'm still busy trying to catch
up with everything that needs to be done this week.  (And this issue
while obviously important, has a number of obvious workarounds, so is
less urgent than some of the security issues with other (non-iMatix)
products I've been dealing with today.)

Ewen

-- 
Ewen McNeill, Technical Consultant, iMatix Corporation  www.imatix.com