realpath patch

php.internals

Andi Gutmans

21 years ago
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

Sara Golemon

21 years ago
> 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

Andi Gutmans

21 years ago
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

Rasmus Lerdorf

21 years ago
On Fri, 1 Oct 2004, Andi Gutmans wrote:
> 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

Sander Steffann

21 years ago
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

Sara Golemon

21 years ago
> With safemode on they can't do this symlink trick directly from > php because PHP's symlink() 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

Rasmus Lerdorf

21 years ago
On Fri, 1 Oct 2004, Sara Golemon wrote:
> > 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

Andi Gutmans

21 years ago
Yep I agree. That makes sense to me. Andi At 12:01 PM 10/1/2004 -0700, Rasmus Lerdorf wrote: