Hi,
On Mon, 26 Jul 2004 10:39:42 +0200
Jakub Vrana <vrana@php.net> wrote:
> > Is there any way restricting people from retrieving file names (where
> > open_basedir and safe_mode obviously won't help), besides adding glob to
> > disable_functions in php.ini?
> If I understand you correctly, only files owned by script owner (thus
> potentially Apache user) are disclosed.
If using safe_mode, we can get all files using glob() if the first file
is owned by ourself. It's important to remember, though, that it's
pretty easy to create a file with the same permission as the Apache-user
(create a folder with chmod 0777 and use PHP to copy a file into that
folder - the new file is owned by the Apache-user and has the same UID
as e.g. the session-files.
But even when using open_basedir, the warning still reveals the first
filename, and by refining our glob-string ("/tmp/a*",
"/tmp/b*","/tmp/ba*"), we would be able to figure out names og files and
directories using a realistic small effort (as opposed to brute force).
Using a little effort, we could find almost any dir/filename in the
system (of course, requiring that the Apache user has access to the
folder), even under safe_mode, even under open_basedir, even without
performing the "Copy files to be owned by Apache-user"-trick.
> Because sessions in common directory are not secure independently
> whether you can read the session filenames or not (you can reveal it
> from some logs), it's better to store session files in different
> directories for each virtual host.
I agree - or any other kind of mechanism to separate session files for
virtual host. Though, these directories should not be owned by the
Apache user.
/tmp/ is owned by root, meaning that opendir() in safe_mode wouldn't
work for retrieving all file names in /tmp/ - if
/tmp/session_files/domain1.tld/ is owned by the Apache-user, we would be
able to use opendir() to retrieve all file names.
Again, I think glob() in safe_mode should perform a UID-check for the
directory, not (directory || first_matched_file).
I would hope that some kind of general default-mechanism would be
implemented, instead of requiring the administrator to put up custom
save_path's for each virtual host.
With the popularity of PHP, I don't think it's an assumption we can rely
on.
> This way, user can read other user's session filenames but she can't use
> it for anything.
Well, he won't be able to read or alter the content of the session file.
But if the folder names are revealing the name of the site (like
/vhost/www.company.tld/tmp/session-files/ - remember we are currently
able to retrieve the file names due to glob()'s nature), he would still
be able to hijack other users' sessions for that host!
The result would be more random as he has no influence of the content of
the session.
> We use it on my company's hosting and I believe it's secure enough.
.. if you don't mind your customers being able to hijack other customers'
users' sessions :)
I really would like both glob() and session storage to behave in a
different way per default, though it might be two different cases. But
currently, even:
- with safe_mode-restriction
- with open_basedir-restriction
- with custom session.save_path for each virtual host/user
- without allowing php-scripts of the same UID as the Apache user to be
executed (mostly because of the possibility of bypassing a
safe_mode-UID-check)
.. a user on the hosting server would still be able to figure out
session names for sessions on another host on the same server, and would
be able to hijack those sessions.
Even when taking all measures that PHP offers, there still is a issue
with session hijacking!
> P.S. I'm on your side with securing glob() but it will not solve all
> security risks with session files stored in common directory.
Thanks - and I agree, though if glob() was fixed (no disclosure in
warnings and only check UID for directory), safe_mode might actually be
enough to prevent session file names being revealed. A user could still
alter his own session file, though.
If it isn't possible to hide the file names, another solution might be
to store a hash (e.g. md5) of the session id instead of the name of the
session id itself, as PHP always goes from user data to session file,
and not the other way around. For a user with the session name
"deadbeefdeadbeefdeadbeefdeadbeef", data could be stored in
sess_(md5sum of "deadbeefdeadbeefdeadbeefdeadbeef").
That way, gaining access to the file name of a session file wouldn't
allow you to hijack that session, since you wouldn't have the original
session name (but only the hashed value).
--
- Peter Brodersen
