ID: 20302 Comment by: real_triad at hotmail dot com 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:
why not just fix the bug cause my server already become a victim of this bug Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2002-11-07 12:20:30] linux_4ever at yahoo dot com Upon investigating the php engine as shipped by RedHat 8.0 with the env_audit program, I have found that php is leaking descriptors (above and beyond what apache is leaking). One descriptor is the php webpage being executed, and 2 copies of the socket returned from accept appear to be leaked. The env_audit program is listed at freshmeat.net, it comes with instructions to audit php. The fix is to add a fcntl(fd, FD_CLOEXEC) after accept and after opening the page. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=20302&edit=1
