ID: 20302 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Scripting Engine problem Operating System: Linux 2.4.18 PHP Version: 4.2.2 New Comment:
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". Previous Comments: ------------------------------------------------------------------------ [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] [EMAIL PROTECTED] >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-12-05 07:27:02] [EMAIL PROTECTED] I got the e-mail stating to try the latest tarball. I downloaded it and grep'ed around. I am not sure how to build a rpm of php that is 100% compatible with RedHat 8.0. The e-mail back was terse and didn't say the problem was replicated or fixed. The tarball has no CHANGELOG. Grep'ing did not show FD_CLOEXEC. Since I am not sure about building a rpm and I cannot find what the fix was, how am I to provide feedback? Was the problem replicated? Did your testing show its now fixed? What files were changed? Are there diffs of the affected code? ------------------------------------------------------------------------ [2002-12-04 18:16:22] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. ------------------------------------------------------------------------ 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
