ID: 20302
Comment by: mef at photosight dot ru
Reported By: linux_4ever at yahoo dot com
Status: No Feedback
Bug Type: Scripting Engine problem
Operating System: Linux 2.4.18
PHP Version: 4.2.2
New Comment:
Please read more information (IN ENGLISH) about this bug.
http://security.nnov.ru/search/document.asp?docid=5575
Previous Comments:
[2004-01-23 14:57:44] real_triad at hotmail dot com
why not just fix the bug
cause my server already become a victim of this bug
[2003-02-05 01:00:02] php-bugs at lists dot php dot net
No feedback was provided for this bug for over 2 weeks, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2003-01-20 21:54:41] [EMAIL PROTECTED]
Could you please check this with using PHP 4.3.0 and Apache 1.3.27 if
it's any better? Also, PHP 4.3.0 builds a CLI binary always, it would
be nice to know also if that has
the same leaks..(you don't have to _install_ php to do that? :)
[2002-12-08 11:11:59] linux_4ever at yahoo dot com
>It would be nice if you could give an exact
>description of what descriptors are open for you.
The main problem is with apache 2.x. The listing is huge. There are 2
descriptors per website on the machine + main error log + main access
log just being leaked by mod_cgi. When testing mod_php, I found 3
additional descriptors being leaked. I guess I incorrectly assumed that
this was a php problem. If php does not police or cleanup the
environment that php applications run under, then I guess this bug
report can be closed. I will also make the apache team aware of this
issue, too. My feelings are that apache 2.x really has some problems.
If you are curious about the leaked descriptors, visit :
http://www.web-insights.net/env_audit The env_audit program has full
description and ready to use php script for testing this. There is also
a 50 page report that can be downloaded from that page that gives more
detail than I can list here.
>BTW: The opened script fd can be leaked without
>any security impact.
Maybe and maybe not. If a hole is found in php, people could use this
to overwrite a page making a temporary security problem more permanent.
To do this requires first finding another exploit, then you might be
able to use this for more mischief. Unless there's a compelling reason
not to do so, I would close the fd or set the FD_CLOEXEC flag. My
testing calls a program external to PHP using the passthru() function.
This external program should not have access to PHP files.
So, I leave it to your team. I won't object to closing this bug report
if you feel the issue truly lies with apache 2.x. Thanks for looking at
it.
[2002-12-05 13:09:27] [EMAIL PROTECTED]
It would be nice if you could give an exact description of what
descriptors are open for you. Like a directory listing
...
ls -la /proc/pidofapache/fd
BTW: The opened script fd can be leaked without any security impact.
And it is an apache bug that the fds are leaked. PHP does no
accept (its the apache child that accepts). And mysql etc... sockets
are opened by the mysqlclient libs... these are responsible for setting
the close on exec flag, not PHP.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/20302
--
Edit this bug report at http://bugs.php.net/?id=20302&edit=1
