In article <p05100304b8e3cee5ab0c@[]>,
 [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?


> 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 

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.


PHP General Mailing List (
To unsubscribe, visit:

Reply via email to