Bogus PHP DoS Attacks
On August 1, 2000, a security oriented newsletter from
e-softinc.com helped turn a simple programming language feature
into a new security threat. Listed among their top ten security
related news items for July, was one from SecurityWatch.com titled
"PHP Eminently DoS-able." The page that this article responds to
and SecurityWatch.com are both gone now, but an archived copy of
the page is available at the
While the specifics of
this incident are now obsolete, the danger of misinformed
over reaction to some reported "bugs" remains relevant.
Selection for the "Top 10" is
based on clickthroughs. Given the title, it's hardly surprising
that it got a lot of clickthroughs. PHP has become the most
popular tool for developing dynamic web content. Anyone who
uses PHP, would want to see what the article was about.
This page is a request that those who post reports of security
problems actually do some research, and attempt to understand a
problem before labeling something as a new security threat. If
the editors at a security related site don't understand the
issues, they should seek some expert opinions, and if they are divided,
include the opposing points of view. In my opinion,
SecurityWatch.com should not have reported this, at least not
without some informed commentary, and e-softinc.com should not
have linked to it, at least without some background.
The SecurityWatch.com piece opens with "(07/20/2001) Russia's own
Ilya Teterin has alerted users to a potential denial-of-service
vulnerability in PHP." It mentions that PHP includes the ability
to access files via HTTP. The supposed "bug" is that someone with
malicious intents, can write a PHP script that calls itself, creating
an endless loop that eventually consumes all the server resources.
Duh. For starters the malicious attacker has to have write
rights to the PHP script area. Either this malicious person is
already a bad guy customer or employee or an intruder who has
compromised the system via other means. If the latter, writing
juvenile buggy code, hardly seems how they are likely to spend
I don't know of any programming language, that doesn't include
features that allow any programmer to exhaust all resources to
which the program has access. Any language that supports
recursion can create an infinite loop with a function calling
itself until all stack space and or memory available to the
process is exhausted. This supposed new PHP bug, is nothing other
than a special case of this. A program that writes to disks can
fill all the disk space it has access to. A program that
allocates memory can allocate all memory that it is allowed to.
Should we disallow recursion, disk writes and memory allocation?
Obviously not if we want our programs to do anything useful. The
operating system, should place constraints on how much disk, memory
or any other finite resources, a process can allocate to itself.
As for this PHP "bug", is it not possible for requires and includes
of local files to create similar resource exhausting endless loops.
If this is what's being discussed then the "HTTP" part of the reported
"bug" is incidental.
On the other hand if the discussion is focused on executable code
obtained via HTTP only, then why focus on the most benign of the
possible bad uses to which such code could be put. Given that
foreign code has been imported and is running with the same
privileges as the PHP process or possibly as an authenticated
user, then this code could do anything that any local code (it is
now local) in the same security context can do. It could erase
disk content to which it has write access, e-mail directory tree
listings of the web site or possibly other directories, e-mail any documents or data
that's part of the PHP application system where the imported code
is executing, or any other documents to which those processes have read
access. The list of damage is constrained only by security set
up on the server where the imported code is executing, and the
imagination of the malicious author. Of course to do any of this,
the author needs to know that his or her code is actually being
included and executed as part of PHP applications on remote sites.
PHP is a general purpose programming language that will do what it's
told to do. If that is stupid or dangerous, then the results will be
stupid or dangerous. Anyone stupid enough to write programs that
import executable statements, from sources over which they have anything
less that full control, is a fool who will get what they deserve.
This is not a PHP bug but rather a reporting bug. Some of these people
are so ignorant and gullible that all someone has to do to get their
attention and web space is announce a new "bug" that is nothing other
than a programing language feature that is so trivial and obvious that no
responsible person would consider mentioning it as a bug. Then it's
labeled with scare tactic headlines, that draw those interested in the
affected product, to the web site and finally someone else gives the whole
thing credence as a "top ten" item. Those that have the experience
to evaluate the story, leave grumbling because they've been duped to
come to a pointless web page, and those who don't, wonder if they should
avoid a potentially useful product feature, because someone else
thought of an irresponsible way to use it.
Maybe I'm missing something here. From what was said at SecurityWatch,
I sure can't think of it. If you can, please let me know and I'll
update this page accordingly. Six years after I wrote this not a single
person wrote to criticise anything I said.
Top of Page -
Copyright © 2000 - 2014 by George Shaffer. This material may be
distributed only subject to the terms and conditions set forth in
These terms are subject to change. Distribution is subject to
the current terms, or at the choice of the distributor, those
in an earlier, digitally signed electronic copy of
http://GeodSoft.com/terms.htm (or cgi-bin/terms.pl) from the
time of the distribution. Distribution of substantively modified
versions of GeodSoft content is prohibited without the explicit written
permission of George Shaffer. Distribution of the work or derivatives
of the work, in whole or in part, for commercial purposes is prohibited
unless prior written permission is obtained from George Shaffer.
Distribution in accordance with these terms, for unrestricted and
uncompensated public access, non profit, or internal company use is