Joost Pol wrote: > This will only help when the directory specified in the open_basedir > directive is a directory in which php code is not interperted. Or a > directory which is not accesible by the user. > > If the directory specified is still accesible by the user, a "malicous" > user could log php-code to an error log and have it interperted. > > Since the error log would be owned by the uid of the webserver, > the phpcode logged to the errorlog will be executed with the uid > of the webserver. > > (eg: log 'showsource($foo)' to bar.php3 and then later execute the > bar.php3 script. bar.php3?foo=/path/to/access_log) > > The user could then read and/or write to files owned by the uid of > the webserver. (not a Good Thing) Again I disagree. For me there are 2 cases: 1) A user with a valid PHP dev. access (via FTP for exemple). His scripts run in safe_mode and are limited with open_basedir. As error_log is limited by open_basedir, he cannot use this function to escape from open_basedir and break safe_mode. And creating an error log in open_basedir with PHP code in it, is not a problem as we have assume that the user have a valid PHP dev. access in open_basedir. > An attacker could upload a simple script that does the following: > > <? > $cmd = '<? showsource($foo); ?>'; > error_log($cmd,3,"/path/to/user/wwwspace/nobody.php"); > ?> 2) An attacker user who can upload and execute a PHP script 's1' (this is what you assume in your description) with error_log call in it in order to generate another file with PHP code 's2' in it. It should be must simplier to directly upload 's2', isn't it ? And if for you error_log is a security problem, I guess fopen/fwrite ... are also a security problem as the attacker can also use fopen/fwrite function to create the file 's2' in /tmp for example. In this case the problem is that the attacker is able to upload and execute a PHP script. And this is not PHP safe_mode fault. So for me error_log do not break safe_mode. -- Laurent Papier - Admin. systeme Sdv Plurimedia - <http://www.sdv.fr>
This archive was generated by hypermail 2b30 : Tue Jul 03 2001 - 12:52:46 PDT