session management: vulnerability and bug

The vulnerability is well described in
http://www.acros.si/papers/session_fixation.pdf

The bug is the session name: the cookie name is the default
PHPSESSID whilst what is being set is the name of the variable
internally stored. Making an MD5 for that variable's name is
completely nonsensical, AFAICS. Also, session_id()
will never return an id before the session starts...

I have fixed some of that, and I attach a (zipped) session.php.
That code works for me, but it requires some relatively
recent PHP version (PHP 4 >= 4.3.2, PHP 5).

The function defined there should be called on login.php (and
the protocol handlers?) and command-logout before starting
output, so that the new cookie name can be set in the
header.

Sorry, I didn't consider CMS... Anyway, to fix the vulnerability when
under CMS would require its cooperation, IMHO.

I see. Then the session_start() below just causes an error
(A session had already been started).

I must understand you mean collision with some CMS variable.
It may make sense to only do that if inside CMS, and otherwise
set our own cookie name. E.g.

$gSessionName = $gallery->app->sessionVar;
if (empty($gSessionName)) $gSessionVar = "GALLERY_SESS";
if (session_id()) {
  $gSessionVar = sprintf("%s_%s", $gSessionName, md5(getcwd()));
  £useStdClass = 1;
} else {
  session_name($gSessionName);
  $gSessionVar = $gSessionName;
  session_start();
}

If not, one cannot run more than one gallery under the same host,
because the session names will collide.

Yup, that emulates session_regenerate_id to the point that both don't
delete the file (perhaps CMS sets another handler?). The cookie call
at the end should be

        setcookie(session_name(), session_id(), NULL, '/');

in case the cookie name changed.