For what it's worth, I just ran this script on my server, and despite the 30 second time limit and 8mb memory limit in php.ini, the script ran longer than 30 secs, CPU usage went between 60% and 100% and my memory usage reached 352000 before I stopped it.
As far as a DoS, I don't think so. A bug? Possibly. Bad coding? Yep. :) Jason Soza ----- Original Message ----- From: CC Zona <[EMAIL PROTECTED]> Date: Wednesday, April 17, 2002 6:21 pm Subject: Re: [PHP] Nasty DoS in PHP > In article <p05100304b8e3cee5ab0c@[210.49.237.250]>, > [EMAIL PROTECTED] (Richard Archer) wrote: > > > At 8:55 PM -0400 17/4/02, Justin Farnsworth wrote: > > > > >This is a rather meaningless thread. It is a > > >security issue that is displaced. > > > > If PHP is not honoring the time limit and memory usage directives > > when outputting headers, then this is a bug in PHP. > > A big "if", since the OP has not yet verified that the time limit > and > memory limit are in effect at the outset of the loop as supposed. > Someone > else want to test for this scenario? Someone, that is, who can > deliberately bring down their server without getting kicked off > permanently? > Meanwhile... > > > If this allows a DoS attack, then this is a very real security > problem. > Why should it? Even if there is a verifiable bug allowing > time/memory > limits to be exceeded when header() goes into an infinite loop, > how could > someone exploit this from the outside? If a scripter is letting > any random > web visitor put their script into an infinite loop, then the > results are at > *least* as much the scripter's fault as PHP's. Ditto for the > scripter who > sets the infinite loop himself while allowing the web user to > specify what > function gets executed in the loop. And if neither of these is > happening, > then where's the DoS? As has already been pointed out, someone > bringing > down their own server with their own code, isn't a DoS. It's > usually poor > coding, and _possibly_ (see above) attributable to a bug, but it's > not a > DoS. > > As far as I can tell, the only security problem here is the usual > one: > figuring out who is clueful enough and responsible enough to be > trusted > with access to operations which can compromise the server. > > Whether there is a bug or not remains an open question. I'll be > curious to > hear whether anyone is able to reproduce a server crash in spite > of > set_time_limit(30) and ini_set("memory_limit","8M") conditions. > > -- > CC -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
