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.

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.

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).

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/msg000
49.html

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.

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

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

Ran into the same problem.

I'm appalled that a bug this big isn't fixed more than a year after it
was reported.

Can't you use FastCGI and avoid issues like these completely?

Any news? mail() function is suffering from the 
same problem, and exim is using Apache port then..

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?

I think that's exactly what FD_CLOEXEC does.

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.

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.

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)

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.

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?

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

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.

SO, can this problem be fixed within PHP/Apache or it cannot?
Do you think using funny scripts started by cron is a solution?

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.