⇥ Now showing: PHP’s true colours

August 29, 2007
17 comments
 
⇥ Permalink

Suppose you’re a hacker. Suppose you’ve found a vulnerability in the current PHP 4 codebase. What would you do?

The scenario above is not that unlikely. Security researchers like Stefan Esser have found a number of vulnerabilities in the PHP codebase, which they have disclosed and helped fix in the past.

However, for every honest Esser out there, it’s safe to think that there are plenty of less well-intentioned people who may be able to find security issues in PHP without feeling compelled to disclose them. If they want to wreak havoc, all they have to do is wait eleven months and let all hell break loose.

The PHP 4 end-of-life announcement should be sending everyone who runs a PHP 4-based system scrambling to port their software to a newer version of PHP—or, maybe, to another language whose developers don’t feel like writing a 300-message thread to choose a keyword (sorry, internals subscribers—I love you all, but I couldn’t resist poking fun at this).

As usual, however, a lot of people are asleep at the wheel, and a lot more are just scratching their heads—likely wondering “how am I supposed to do this?”

Of these, I’m sure that a large number are owners of small hosting firms—which, by far, provide the vast majority of PHP-powered websites that Netcraft carefully tracks for us—that sell cheap shared hosting. You see, they have a rather large problem: cheap hosting makes for small profits and noisy customers.

If you provide shared-hosting plans, it’s likely that your servers are still running PHP 4. Upgrading to PHP 5 is a logistical nightmare for two reasons: first, you don’t necessarily know that you’ll be able to properly set up and secure your systems; second, you don’t know that your customers’ applications will keep on running.

The dark art of running PHP
The PHP mailing lists are littered with comments along the lines of this one—from folks who are trying to figure out how changes in the PHP codebase are going to affect their business (in this case, in the long term, but there are plenty of problems that are going to show up in the short term, too).

Hosting is essentially a numbers business. You need a given number of customers per server and a given number of servers to cover your costs—of which things like hardware, bandwidth and utilities are usually not the largest. With margins already razor-thin, having to invest in figuring out how to properly secure a server can push you over the edge—and many may choose to simply sit things out and let PHP 4 run longer than its shelf life really allows.

The customer dilemma
Hell hath no fury like a customer scorned. And the amount of fury, in my experience, is inversely proportional the amount spent. It’s unlikely that folks who decide to spend $5.99 a month for hosting have the know-how or resources to deal with porting their code from a PHP 4 base to PHP 5. What’s more, code that runs on these low-end hosting accounts is likely to be poorly written or rely on archaic techniques that have been progressively obliterated by the PHP development team because of their inherent lack of performance or unsafety.

If a hosting company simply upgrades to PHP 5, it’s well possible that the code run by a large number of its customers is simply going to stop working. Are these customers going to blame their own poor software product? Of course not—it was working before.

If there’s anyone they’re going to blame, it’s going to be the hosting companies—and, when you’re making $6 a month from a customer, a single e-mail is enough to turn whatever tiny profit you can make into a loss—particularly so because the customer is unlikely to know understand what the problem is.

What can we do?
The consequences of doing nothing can be catastrophic. Hosting companies that fail to upgrade run the risk of leaving their customers exposed to potentially serious flaws that could wreak all sorts of havoc with their code. As a community, we cannot afford to let this happen—because whatever backlash is going to take place will eventually trace its way to PHP itself.

If you own a hosting company, now is the time to let your customers know that the switch is coming. You should get your PHP 5 servers set up now and offer incentives for customers to switch their sites as soon as possible—it’s going to cost you some money now, but it will save you considerably in the future. You should also consider setting up resources that can help your customers with the switch—such as a web pages with links to relevant documentation, or a marketplace for your less tech-savvy customers to find inexpensive help to port their code over.

If you are part of the community, the best thing that you can do is to help provide a clear upgrade path from PHP 4 to PHP 5. We at php|architect are making preparations to provide a well-organized set of resources for this purpose, and there are a number of resources already available out there.

Make no mistake about it: the success and penetration of PHP 4 make this a prime problem that can have some very dire consequences on PHP itself. If nothing is done about it, when can kiss our 20 million PHP-powered sites goodbye.