Hey,
I'd like to commit the realpath() patch I sent to the list for review a
week or so ago. Unless there are any objections I'll commit it (to HEAD) in
1-2 days. This will give it some more exposure and will have more people
testing it.
Andi
I'd like to commit the
realpath()patch I sent to the list for review a
week or so ago. Unless there are any objections I'll commit it (to HEAD)
in
1-2 days. This will give it some more exposure and will have more people
testing it.
Somehow the patch is no longer in my news spool, so rather then looking at
the source I'll just ask: Are all uses of VCWD_REALPATH() effected by this?
If so it could provide a means to bypass basedir checks (and possibly
certain parts of safe_mode). A scripter on a shared host could create a
symlink, get the cache to catch it, then change the symlink to point to a
different (ordinarily restricted) location, then do normal file ops letting
the basedir check believe that the script is accessing a valid location.
Can we roll in a VCWD_REALPATH_NO_CACHE() macro to avoid problems like this?
-Sara
At 11:24 AM 10/1/2004 -0700, Sara Golemon wrote:
I'd like to commit the
realpath()patch I sent to the list for review a
week or so ago. Unless there are any objections I'll commit it (to HEAD)
in
1-2 days. This will give it some more exposure and will have more people
testing it.Somehow the patch is no longer in my news spool, so rather then looking at
the source I'll just ask: Are all uses of VCWD_REALPATH() effected by this?
If so it could provide a means to bypass basedir checks (and possibly
certain parts of safe_mode). A scripter on a shared host could create a
symlink, get the cache to catch it, then change the symlink to point to a
different (ordinarily restricted) location, then do normal file ops letting
the basedir check believe that the script is accessing a valid location.Can we roll in a VCWD_REALPATH_NO_CACHE() macro to avoid problems like this?
http://snaps.php.net/~andi/realpath_cache2.diff
Hmm, you are quite a hacker :)
I think you might be on to something. Can you take a look and see what
changes we'd require?
Andi
At 11:24 AM 10/1/2004 -0700, Sara Golemon wrote:
I'd like to commit the
realpath()patch I sent to the list for review a
week or so ago. Unless there are any objections I'll commit it (to HEAD)
in
1-2 days. This will give it some more exposure and will have more people
testing it.Somehow the patch is no longer in my news spool, so rather then looking at
the source I'll just ask: Are all uses of VCWD_REALPATH() effected by this?
If so it could provide a means to bypass basedir checks (and possibly
certain parts of safe_mode). A scripter on a shared host could create a
symlink, get the cache to catch it, then change the symlink to point to a
different (ordinarily restricted) location, then do normal file ops letting
the basedir check believe that the script is accessing a valid location.Can we roll in a VCWD_REALPATH_NO_CACHE() macro to avoid problems like this?
http://snaps.php.net/~andi/realpath_cache2.diff
Hmm, you are quite a hacker :)
I think you might be on to something. Can you take a look and see what
changes we'd require?
The only real way around this is to not cache when safemode is on. The
whole point of the realpath cache is to assume that the directory
structure on a server doesn't change very often, which is normally the
case. If someone changes it on purpose underneath it, all bets are off.
On the other hand, if someone has access to make directory structure
changes on the server in most cases they have already gotten around
safemode. With safemode on they can't do this symlink trick directly from
php because PHP's symlink() safemode checks source and target paths. The
only case that trips us up is the one where a user has direct access to
create whatever symlinks he wants in his own directory and then by hitting
that symlink through the web server he is effectively reading any file the
web server user id has permission to read and thereby bypassing safemode.
But like my syscall patches, realpath caching isn't something all that
many really need. Turning it off when safemode/open_basedir is on should
be fine.
-Rasmus
Hi,
But like my syscall patches, realpath caching isn't something all that
many really need. Turning it off when safemode/open_basedir is on should
be fine.
Sounds good to me.
Sander
With safemode on they can't do this symlink trick directly from
php because PHP'ssymlink()safemode checks source and target paths.
Good call...
The
only case that trips us up is the one where a user has direct access to
create whatever symlinks he wants in his own directory and then by hitting
that symlink through the web server he is effectively reading any file the
web server user id has permission to read and thereby bypassing safemode.
I wouldn't consider it uncommon for shared hosting users to have a shell
account....
But like my syscall patches, realpath caching isn't something all that
many really need. Turning it off when safemode/open_basedir is on should
be fine.
I can agree with that. Even though the caching would be a real
"nice-to-have". It's much cleaner to just disable it in cases where it'll
cause more harm than good.
I do want to point out that the current form of the patch won't build
under ZTS though. virtual_file_ex has no TSRMLS_DC in its declaration but
it makes use of CWDG().
-Sara
The
only case that trips us up is the one where a user has direct access to
create whatever symlinks he wants in his own directory and then by hitting
that symlink through the web server he is effectively reading any file the
web server user id has permission to read and thereby bypassing safemode.I wouldn't consider it uncommon for shared hosting users to have a shell
account....
I haven't really kept up with what ISP's are doing these days, but I would
hope they would be chroot'ing ot jail'ing these shell accounts?
-Rasmus