php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #38915 Apache: system() (and similar) don't cleanup opened handles of Apache
Submitted: 2006-09-21 19:15 UTC Modified: 2010-12-01 16:19 UTC
Votes:138
Avg. Score:4.8 ± 0.6
Reproduced:115 of 121 (95.0%)
Same Version:50 (43.5%)
Same OS:84 (73.0%)
From: dimmoborgir at gmail dot com Assigned:
Status: Analyzed Package: Program Execution
PHP Version: 5.2.2, 4.4.7 OS: UNIX
Private report: No CVE-ID:
Have you experienced this issue?
Rate the importance of this bug to you:

 [2006-09-21 19:15 UTC] dimmoborgir at gmail dot com
Description:
------------
The problem is in exec, system, popen (and similar) PHP functions. The fact is that PHP doesn't sanitize opened file descriptors before executing a program.

These functions use popen() C function to spawn a program.
popen() is equal to the successive execution of
pipe(), fork(), dup2(), exec().
These functions keep all opened handles. (Except STDOUT, which is replaced to pipe).

This bug makes php-includes vulnerabilities more dangerous.
If the server uses mod_php, and we can execute shell commands via system(), then we can, e.g. stop apache processes (by sending a SIGSTOP), and to listen and process connections on 80 port (opened by Apache, and transmitted to us by PHP). Also we can write anything to its errorlog.

Reproduce code:
---------------
Some steps to reproduce a bug.
First. Simple program to wait :)

# cat test1.c
int main()
{
   setsid( );
   sleep( 10000 );
}

#gcc -o test1 test1.c

Ok. Let's make a php script:
#cat a.php
<?php
   system( "./test1" );
?>

Request: http://127.0.0.1/a.php

Good. Now see opened handles:

#lsof | grep test1
test1     cwd        DIR      /usr/local/apache2/htdocs
test1     rtd        DIR      /
test1     txt        REG      /var/www/html/test1
test1     mem        REG      /lib/tls/libc-2.3.5.so
test1     mem        REG      /lib/ld-2.3.5.so
test1     mem        REG      [stack] (stat: No such file or directory)
test1       0r       CHR      /dev/null
test1       1w      FIFO      pipe
test1       2w       REG      /usr/local/apache2/logs/error_log
test1       3u      IPv4      *:http (LISTEN)
test1       4r      FIFO      pipe
test1       5w      FIFO      pipe
test1       6w       REG      /usr/local/apache2/logs/error_log
test1       7w       REG      /usr/local/apache2/logs/access_log
test1       8r      0000      unknown inode type
test1       9u      IPv4      10.0.0.2:http->10.0.0.1:2134 (CLOSE_WAIT)

So, our test1 has apache's handles. Now we can do something like that:

 int p = getsid( 0 );     // get current Process Group Id
 setsid( );               // become session leader	
 kill( -p, SIGSTOP );     // good night, Apache Process Group :)

And after that:

 for ( sock = 3; sock < getdtablesize(); sock++ )  // find valid socket handle
    if ( listen (sock, 10) == 0 ) break;
    
Full exploit is available on http://hackerdom.ru/~dimmo/phpexpl.c

Expected result:
----------------
I didn't expected program, executed via system() PHP function, to have all opened descriptors of Apache Web Server (including 80 port, error and access logs, opened connections, etc...)

Actual result:
--------------
Our PHP program has all descriptors of Apache Server.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-10-20 09:48 UTC] sesser@php.net
Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

The opened file descriptors are opened by Apache.
It is the job of Apache to protect them, not something that should be reinvented in all apache modules.

Not a bug in PHP.
 [2006-10-30 16:55 UTC] jlawson-php at bovine dot net
It should be PHP's responsibility to close all open file handles (after forking but before the exec).
 
Keep in mind that PHP is running as a module within the same process space as Apache, and those private FDs are required for it to operate.  Apache cannot reasonably close and re-open all of those whenever it is invoking a module's handlers, nor can it reasonably run modules in a separate process.  Modules are intended to be trusted code and so Apache does not attempt to protect itself from misdesigned modules.
 
(In the case where PHP is installed as a CGI and not a module, then Apache does indeed close the private FDs prior to running PHP.)
 
For example, when a CGI process via Apache's "mod_cgi", that module is responsible for ensuring that it explicitly closes all open files prior to the exec().  PHP is in a similar situation and should also do the same when executing sub-processes.

Passing blame to Apache by saying that they should use "close on fork" fcntl is not reasonable.  Its current expectation is that modules which need to fork will explicitly close files (as demonstrated by mod_cgi's own implementation).
 [2006-11-23 15:36 UTC] php at vanviegen dot net
It seems that the mail() function is suffering from the 
same problem. It is rather scary to see Apache failing to 
restart, because the MTA (exim in our case) is already 
listening on port *:80 !

More details:
http://www.exim.org/mail-archives/exim-users/Week-of-Mon-20030407/msg00049.html
 [2007-01-04 19:25 UTC] anomie at users dot sf dot net
On 20 Oct 2006 9:48am UTC, sesser@php.net wrote:

> The opened file descriptors are opened by Apache.
> It is the job of Apache to protect them, not something that
> should be reinvented in all apache modules.

If that's your position, then as far as I can tell mod_php should be calling apr_proc_create() instead of system()/popen()/etc and apr_pool_cleanup_for_exec() before exec(). Apache adds (or should be adding) all the FDs that should be closed on exec to a list that those functions make use of.

If you don't like that, then either explain (in as much detail as is required) why that isn't Apache's method of protecting the FDs, find a non-bogus reason for claiming this issue is not a mod_php bug, or just fix the bug already. "Apache should just use FD_CLOEXEC" isn't a non-bogus reason, BTW, although convincing Apache to do so and making sure FD_CLOEXEC is supported on all platforms mod_php can possibly be used on might be an acceptable bugfix.

I've also seen the "MTA ends up listening on port 80" issue after using the php mail functions.
 [2007-03-05 21:11 UTC] oliver at realtsp dot com
apart from the security considerations mentioned above the fact that mod_php doesn't free the FDs when forking prevents us from forking cleanly.

ie we cannot from a web request to mod_php fork a cli process cleanly because it will inherit all the open FDs (ie typically port 80 & 443) even if you use setsid() (or daemon on FreeBSD) etc..

you can see this when you...
fork
stop apache
netstat -an | grep LISTEN

your cli process will be LISTENING to port 80 & 443. this is not only a security risk, but it will prevent apache for restarting:

(48)Address already in use: make_sock: could not bind to address [::]:443
no listening sockets available, shutting down

I have not found any way to close these sockets as they should be because the resource handles are not available in php. If you could at least make these available then we could at least ensure we close them manually.

Regards 

Oliver
 [2007-07-29 10:48 UTC] antoine dot bajolet at tdf dot fr
Hello,

I agree with all contributors :

It's a bunch of pain we can't launch a clean process from a PHP web interface.

Without any technical consideration, functionally it's a real need to numerous PHP users, and for a long time seeing those bug reports :
http://bugs.php.net/bug.php?id=15529
http://bugs.php.net/bug.php?id=15642
http://bugs.php.net/bug.php?id=16548

The only workaround whe found to obtain the result is :
- Writing something to a file to tell "hey, there is a process to launch or stop"
- Using a cron'ed script to read the file and launch/stop the process if it tells it.

And this poor tip is far far from satisfying us.

The last response given in 2003 was
"Given the nature of PHP's execution architecture this is not
possible/practical to implement."

But if the Apache API offers a "apr_proc_create()" function, why not using it in mod_php ? There are some other differences between mod_php and php-cli.


Regards,
Antoine
 [2007-10-07 09:33 UTC] Cruz at guerillamail dot com
Ran into the same problem.

I'm appalled that a bug this big isn't fixed more than a year after it was reported.
 [2007-11-25 19:57 UTC] olafvdspek at gmail dot com
Can't you use FastCGI and avoid issues like these completely?
 [2007-11-29 20:33 UTC] odeta at hard dot lt
Any news? mail() function is suffering from the 
same problem, and exim is using Apache port then..
 [2007-12-04 18:43 UTC] crescentfreshpot at yahoo dot com
Just to add to the dialog, Apache 1.x seems to have tried to address the issue of leaked FDs itself. http://www.apache.org/dist/httpd/CHANGES_1.3 says:

Changes with Apache 1.3.28

*) Certain 3rd party modules would bypass the Apache API and not
   invoke ap_cleanup_for_exec() before creating sub-processes.
   To such a child process, Apache's file descriptors (lock
   fd's, log files, sockets) were accessible, allowing them
   direct access to Apache log file etc.  Where the OS allows,
   we now add proactive close functions to prevent these file
   descriptors from leaking to the child processes.

As far as I understand the above, apache thinks it can know when [mod_]php does a system-level popen() and cleanup the parent FDs before exec(). Is that actually possible?
 [2007-12-04 19:14 UTC] stas@php.net
I think that's exactly what FD_CLOEXEC does.
 [2007-12-06 20:56 UTC] gabe-php at mudbugmedia dot com
I'm also running into a problem where, because my Apache is hosting 500+ 
vhosts, gobbling up 1000+ descriptors for logs.  All this gets passed to 
any program it executes, causing problems with processes with a 1024 
limit compiled in.  Apache might be able to deal with having that many 
descriptors open, but we shouldn't assume anything PHP execs should.
 [2007-12-06 21:41 UTC] jameskyle at ucla dot edu
Whether the blame lie with Apache or PHP is irrelevant. It directly 
impacts the security of PHP. Thus, the PHP team should work on a fix or 
apply substantial and vocal pressure on the Apache team.

This would at least open discourse and allow the two teams to work 
toward a solution and determine the quickest path.

The fact that this has remained a bug for an entire year is 
unacceptable. As is the relative silence on the topic from both of the 
primary development teams.
 [2008-01-29 18:20 UTC] adrian dot rollett at unt dot edu
For those of you that found this page while looking for info on why exim 
is blocking port 80 after inheriting apache's file descriptors, I 
believe I found the reason for this. It seems that exim will only work 
with a maximum of 1000 file descriptors, (or 256 on older systems) after 
which point it will hang, consuming all available cpu cycles, and 
preventing apache from restarting. The only possible solutions I have 
found:

1. modify the source, and re-compile exim with a higher file descriptor 
limit.
2. run a cron job at regular intervals to search for hung exim processes 
and kill them.
3. switch MUAs. (postfix may fail more gracefully, but I haven't tried 
this yet)
 [2008-02-19 03:59 UTC] anomie at users dot sf dot net
On 29 Jan 6:20pm UTC, adrian dot rollett at unt dot edu wrote:
>
> For those of you that found this page while looking for info on why
> exim is blocking port 80 after inheriting apache's file descriptors,
> I believe I found the reason for this. It seems that exim will only
> work with a maximum of 1000 file descriptors, (or 256 on older
> systems) after which point it will hang, consuming all available cpu
> cycles, and preventing apache from restarting.

You should submit more detailed information on this to Exim's bug tracking system so it has a chance of being fixed.


As far as this ridiculous bug, I've been working around it by using a small program that closes all FDs above 2 (either via the F_CLOSEM fcntl, reading /proc/self/fd, or just blindly calling close for every possible fd) and then execs the real program.
 [2008-03-07 10:45 UTC] martin at activevb dot de
Will this ever be fixed... or shall we better rewrite our 30000 lines of PHP code in Perl? :-|

Is it possible to use apr_proc_create() and apr_pool_cleanup_for_exec() directly from PHP source code without patching PHP?
 [2008-04-30 00:06 UTC] support at ppnhosting dot com
5.2.3
also experiencing this 'bug' to the point of having to manually kill Exim to just Apache restarted.. the mail() function is suffering from the same problem. It is very annoying to see Apache failing to 
restart, because the MTA (exim via sendmail in our case) is already 
listening on port *:80
 [2008-05-27 15:12 UTC] jeroen at unfix dot org
My solution to this very annoying issue (especially when Apache is reloaded and the from PHP spawned app is still running and your webserver thus simply dies off as the apache processes are gone, but the spawned app keeps port 80 etc open for you, thus making Apache never start again...

http://unfix.org/~jeroen/archive/closedexec.c

Compile: cc -o /usr/bin/closedexec closedexec.c

Just call it like: system("/usr/bin/closedexec /path/to/exe arg arg arg") or whatever call you where using in PHP.

It first closes all sockets !1|!2 (stdout/stderr), setsid()'s, forks, and then execv's the args given, doing a waitpid() in the other thread and killing the process when it runs longer than 5 minutes.
 [2008-08-20 13:28 UTC] peterspoon at abv dot bg
SO, can this problem be fixed within PHP/Apache or it cannot?
Do you think using funny scripts started by cron is a solution?
 [2008-08-26 13:08 UTC] anomie at users dot sf dot net
It seems that it could easily be fixed by having mod_php use the Apache-provided functions which are intended to solve exactly this problem, but the PHP developers seem to have decided to ignore this bug instead.

Rather than a cron script, use a trampoline program like the one posted by jeroen at unfix dot org; we have something similar here, although ours doesn't impose an arbitrary run time limit.
 [2009-06-25 16:07 UTC] virus at tgu dot ru
OMG...
It's still didn't fixed... :(
 [2009-07-03 00:38 UTC] rasmus@php.net
This is finally fixed in Apache now.

https://issues.apache.org/bugzilla/show_bug.cgi?id=46425

It really is the responsibility of initiator of an fd to set the O_CLOEXEC flag on it.  Going back and trying to do it after the fact is really messy because we don't have direct access to these fds.  Since I can't think of a portable way to get a list of all open fds, we would have to pick some arbitrary number and loop through and set FD_CLOEXEC on the first N fds.

Something like this:

Index: ext/standard/exec.c
===================================================================
RCS file: /repository/php-src/ext/standard/exec.c,v
retrieving revision 1.113.2.3.2.13
diff -u -r1.113.2.3.2.13 exec.c
--- ext/standard/exec.c	30 Apr 2009 15:25:05 -0000	1.113.2.3.2.13
+++ ext/standard/exec.c	3 Jul 2009 00:35:25 -0000
@@ -101,6 +101,17 @@
 	sig_handler = signal (SIGCHLD, SIG_DFL);
 #endif
 
+#if defined(F_SETFD) && defined(FD_CLOEXEC)
+	{
+		int i, oldflags;
+		for(i=0; i<10; i++) {
+			oldflags = fcntl(i, F_GETFD, 0);
+			oldflags |= FD_CLOEXEC;
+			fcntl(i, F_SETFD, oldflags);
+		}
+	}
+#endif
+
 #ifdef PHP_WIN32
 	fp = VCWD_POPEN(cmd_p, "rb");
 #else

and something similar would have to be done in the other places we fork, like in mail().  This is extremely ugly, as far as I am concerned, and likely doesn't catch everything anyway.

If someone sees a clean way of fixing this that I have missed, please let us know.  Otherwise I would encourage you to upgrade your Apache or lean on whatever web server you are using that is passing dirty fds to us.

 [2009-12-23 18:45 UTC] devrim at kodingen dot com
Apparently Jeroen's closedexec.c code is not available from his website,

here is my copy: http://pastie.org/754717

It is very useful to us, and that fix is still not there.
 [2010-02-22 19:16 UTC] ionut dot dumitru at webland dot ro
the problem is still there in 5.2 just with php not involving apache.
so i write a cli daemon A which uses a listener socket , at some point it starts another daemon B with any of exec/system/popen etc. 'A' works as a sort of supervisor for B so i can't shut it down. but at some point i need to restart A, well I can't cause it won't bind to the same listener address anymore because B is keeping the handles open. spent a lot of time but i guess i have to go the file/cron way since php can't clean itself.
 [2010-04-16 01:31 UTC] crrodriguez at opensuse dot org
In linux, this should fix the issue for mail()

diff --git a/ext/standard/mail.c b/ext/standard/mail.c
index ab65f16..a8b3bf5 100644
--- a/ext/standard/mail.c
+++ b/ext/standard/mail.c
@@ -288,8 +288,12 @@ PHPAPI int php_mail(char *to, char *subject, char *message, 
char *headers, char
         * (e.g. the shell can't be executed) we explicitely set it to 0 to be
         * sure we don't catch any older errno value. */
        errno = 0;
+#if defined(__linux__) && defined(__GLIBC__) &&  __GLIBC_PREREQ(2, 9)
+       sendmail = popen(sendmail_cmd, "we");
+#else 
        sendmail = popen(sendmail_cmd, "w");
 #endif
+#endif
        if (extra_cmd != NULL) {
                efree (sendmail_cmd);
        }


Note that you need glibc 2.9 though.
 [2010-12-01 16:19 UTC] jani@php.net
-Package: Feature/Change Request +Package: Program Execution
 [2012-10-31 23:56 UTC] oliver at realtsp dot com
we solved by passing the forked/exec'd process through a bash shell and closing 
all te file 
descriptors: eg: (note this is for FreeBSD using daemon, but "nohup" should work 
on linux)

daemon /usr/bin/env bash -c 'exec 0<&-; exec 1> /path/to/error/log; exec 2> 
/path/to/stdout/log; 
eval exec {3..255}\>\&-; /usr/bin/env php /path/to/script args...'

Note we find it crucial to redirect and NOT CLOSE STDOUT and STDERR because 
otherwise you will 
never find out if sth is wrong with forked process. You should ensure that they 
exist and are 
writable before forking. 

The trick with eval exec {3..255}\>\&-;  is from here:
http://blog.n01se.net/blog-n01se-net-p-145.html

This works for us in a php-fastcgi situation. the fastcgi-socket and the mysql 
socket are both 
closed successfully. the new process opens its own mysql socket just fine...

I suspect this is similar to what Jeroen's closedexec.c does, but no need for a 
c program. 
Everyone should have bash. 

If you redirect the stdout of above fork command to a file and check the 
contents of that daemon 
gives you nice messages, just append 

 2> /path/to/temp/stderr/file/for/daemon/messages

to the above command.

We have the construction of the fork command wrapped in a simple function, like 
so:

    $exec_cmd = ((php_uname('s') == 'FreeBSD') ? 'daemon' : 'nohup') .                  
// try to 
be OS agnostic, daemon = fork, setguid etc, but don't close stderr with -f         
      ' /usr/bin/env bash -c ' .                                                        
// wrap 
actual call to new php process in a shell (use env!), so                             
      // must escape here in case the already escaped args contain                                                                                                                   
      // specials chars like single quotes (which the will!)                                                                                                                         
      escapeshellarg(
        'exec 0<&-; ' .                                                                 
// close 
STDIN                                                                               
        'exec 1> ' . escapeshellarg($app_log) . '; ' .                                  
// STDOUT 
> app_log                                                                          
        'exec 2> ' . escapeshellarg($error_log) . '; ' .                                
// STDOUT 
> error_log                                                                        
        'eval exec {3..255}\>\&-; ' .                                                   
// we can 
close all other fds (fastcgi, mysql, etc)..eval trick!                             
        '/usr/bin/env php ' . BASE . $cmd . ' ' .                                       
// call 
php (with env!) don't rely on shebang or exec perms                                  
        join(' ',                                                                       
// add 
args separated by spaces                                                              
             array_map(function ($arg) { return escapeshellarg($arg); }, $args))        
// after 
escaping them                                                                       
        );


Sorry about the formatting...
 [2013-12-03 17:23 UTC] brak at gameservers dot com
This same issue appears to happen with PHP-FPM (I am using nginx as the webserver, but that shouldn't matter).  PHP version 5.4.22 on Linux (CentOS 6.5)


Quick example:
<?php
        $p = popen('/bin/bash -c "sleep 60"','w');
        pclose($p);
?>

Now find the child process (ps aux | grep sleep) and lsof -p XXX -n:

sleep   13443 nobody    0r  FIFO      0,8      0t0 10237775 pipe
sleep   13443 nobody    1u   CHR      1,3      0t0     3920 /dev/null
sleep   13443 nobody    2u   CHR      1,3      0t0     3920 /dev/null
sleep   13443 nobody    4u  IPv4 10236693      0t0      TCP 127.0.0.1:cslistener->127.0.0.1:53151 (ESTABLISHED)
sleep   13443 nobody    9u   REG      0,9        0     3918 [eventpoll]


FD 4 there is the TCP connection from the PHP worker process to the web server.
 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Mon Apr 21 00:02:04 2014 UTC