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
