If nobody wants to give an answer to the above, my question would
still be:
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?

Why don't you set display_errors to Off? Or am I missing something?

Because I can set them On in my script, then go guessing at filenames
on the server.

George

Hi,

On Sun, 25 Jul 2004 11:12:26 -0400 (EDT)
Adam Maccabee Trachtenberg adam@trachtenberg.com wrote:

If nobody wants to give an answer to the above, my question would still be:
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?
Why don't you set display_errors to Off? Or am I missing something?

I'm not that concerned about myself being able to locate files on my own
system :) I'm more concerned about users in a shared environment (as
most webhosting-facilities) would be able to get file names, they
shouldn't have access to.

display_errors is changeable by PHP_INI_ALL, meaning that users would be
able to turn warnings on. Still, I wouldn't like a solution where users
wouldn't have access to warnings, just because of this.

I would hope for a global change (like changing the behaviour of glob() )
making sure that users in a shared environment really are restricted by
safe_mode and open_basedir. I see several behaviours of glob() allowing
users to bypass other security measures.

As mentioned in bug #28932 I would think that glob() should behave the
same way as opendir(). As it is now, errors would regard the files
globbed and not the directory itself. If it behaved like opendir(), we
would get rid of the following issues:

• glob() checks UID of directory or first file, instead of just
  directory. First file-check makes no sense (1)
• No "file walking" would be possible (as glob() returns false instead
  of raising a warning if no file is matched) (2a)
• File names wouldn't be disclosed (2b)

--

• Peter Brodersen

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