[imp] Vulnerabilities in IMP/PHP
Bjørn Ove Grøtan
bjorn.grotan@itea.ntnu.no
Mon, 19 Aug 2002 10:09:03 +0200
Excuse my English, but what you're about to read is of somewhat
importance. Admins, developers and users using PHP's session-
handler and/or IMP should read this ->
On a large-scale installation with a clustered web-solution we've found
some vulnerabilities in default PHP-installation and week handling of
sessions from IMP.
Horde/Imp uses only standard session_start() from PHP without much more
magic stuff. The session-key generated by PHP is solely based on time,
though with both seconds and microseconds. In some cases this is
sufficient behaviour, but not in large-scale systems with clustered
webservers IMHO. With enough logins, sooner or later there will be a
chance that two or more users get the same sessionkey - and may
experience various account-interexchanges.
One simple solution is to enable and use entropy.file and entropy.length
in php.ini. If using e.g. /dev/urandom, the session-key-generator adds
16 chars from /dev/urandom which it hashes together with the timestamp,
now we're most likely unable to get to even sessions.
You'll find out if you're using entropy from putting this <?php phpinfo(); ?>
into e.g. phpinfo.php
Another "vulnerable thing" we found was that /tmp/phpsessions was readable for
the web-user. If you have users webpages on the same computers, be shure to
turn off user-dir on your webmail-domain!!! Each active session is stored
in /tmp/phpsessions. After writing a small script, you're able to
"take over" another persons session. Given the sessionid, and username
you can extract all variables IMP stored for this session. Among these
variables, there's a "encrypted" password. The "encryption" concists of
using "imp" and the sessionid as key - which at this time - you have both.
Some general web-admin advisories:
Make shure your webuser (e.g. nobody, www-data) cannot list the phpsessions
file. Doing this, and it makes it a bit more
difficult to find out which sessions that are really active, and if you
know the filename - you basically have the cookie you need anyway.
Turning off the userdir for you webmail-domain may not be enough.
Make shure that the webuser cannor run strace, truss or similar utils
on your e.g. apache-processes.
If e.g. Apache is started as root and new child-processes spawns as
webuser, webuser should not be able to run such utils.
I hope you find these advisories useful!
Best regards
Bjørn Ove Grøtan
IT-Dept.
Norwegian University of Technology & Science
(http://www.ntnu.no)