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 Internet Archive. 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 their time.

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 - Site Map

Copyright © 2000 - 2014 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth in http://GeodSoft.com/terms.htm (or http://GeodSoft.com/cgi-bin/terms.pl). 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 allowed.