> However, quite frankly, this is a lame attack, because all it will do is > consume file descriptors for only the CHILD process the script is > running in. The script will then hit the fd limit of the child process > (most systems around 255 is the default) This will not hurt the process, > because all needed file descriptors were opened before the script was > executed. The beauty of this is that the kernel will the reject all > future calls beyond the limit, which halts i/o usage, and causes the > process to consume more user time, which cause the process to hit max > execution limit.
While the file description attack may be "lame" as you call it and won't cause excessive harm. There are many other ways that 2-3 lines a webserver can be brought down to its knees. If you want I can post code for A LOT more potent attacks that will disable the webserver. I simply choose not to because I believe that disclosing such information will do more harm then good. Even the "lame" file descriptor attack can be made very dangerous by adding of 1 line of code. > The argument you make to remove safe mode because it is not perfect is > unfounded. By the same argument you could say we shouldn't use locks on > our doors, because hey "they can be picked". > Safe mode is not only imperfect it does not even work properly. In the last day and a half I've showed 5 bugs that allow it be bypassed, simply take a look at the latest safe_mode bugs. Some of those were fixed other were not as yet. To continue with your lock analogy, you do not protect your house with a broken lock, because beyond cosmetic value it does absolutely nothing. Ilia -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
