As PHP Group Patches High-Risk Bugs, 62% of Sites Still Use PHP 5 (threatpost.com)

America's Multi-State Information Sharing & Analysis Center is operated in collaboration with its Department of Homeland Security's Office of Cybersecurity and Communications -- and they've got some bad news. MS-ISAC released an advisory warning government agencies, businesses, and home users of multiple high-risk security issues in PHP that can allow attackers to execute arbitrary code. Furthermore, if the PHP vulnerabilities are not successfully exploited, attackers could still induce a denial-of-service condition rendering the probed servers unusable... The PHP Group has issued fixes in the PHP 7.1.23 and 7.2.11 releases for all the high-risk bugs that could lead to DoS and arbitrary code execution in all vulnerable PHP 7.1 and 7.2 versions before these latest updates.
But meanwhile, Threatpost reported this week that 62% of the world's web sites are still running PHP version 5 -- even though its end of life is December 31st. "The deadlines will not be extended, and it is critical that PHP-based websites are upgraded to ensure that security support is provided," warned a recent CERT notice.

So far Drupal is the only CMS posting an official notice requiring upgrades to PHP 7 (by March, three months after the PHP 5.6's end of life deadline). Threatpost notes that "There has been no such notice from WordPress or Joomla."

Comments

Re:5 and, but no mention of PHP 6

[El_Muerte_TDS]

yes

Re:

[Anonymous Coward]

Besides, normally even numbers are used for stable releases. Why would PHP ever be considered dependable or trustworthy as a stable runtime?

PHP 5.6

[Dutch Gun]

Everyone is making it sound like PHP 5.6 is some ancient piece of cruft that everyone has had PLENTY of time to upgrade. In fact, after looking it up, it's only about four years old. That surprised me. It's at end of life already?

Since when is "move fast and break things" a winning strategy for a server-side scripting language which runs much of the world's internet infrastructure? Shouldn't the "deadline will not be extended" attitude perhaps be re-evaluated in light of reality?

We've seen this happen before, of course. Language developers often seem to underestimate how long it takes infrastructure to migrate to newer, incompatible versions of a language. For instance, the Python 2.7/3.x split, which occurred a *decade* ago, is still causing headaches on occasion. At least the Python devs had the good sense to support 2.7 until 2020. I'm going to bet that another four years from now, you'll still see a significant number of sites still using PHP 5.6, official support or not.

Re:PHP 5.6

[gman003]

The old MySQL library (the one whose functions start with "mysql_" instead of "mysqli_", which dates back all the way to PHP2) was fundamentally broken. An API-compatible replacement could not be protected from SQL injection. For that reason, mysql_ was deprecated for the entire 5.x block - issuing increasingly dire warnings with every point release. Finally, PHP7 threw it out because it was the only way to force people to fix their broken insecure code.

In order to have that problem while upgrading, you'd either have to be porting code that went back to PHP4 and hadn't been maintained, or code that was written in a well-known wrong way. Which sure, happens - I cleaned up some mysql_ functions myself while porting code that fell under the former. Took maybe an hour to get it running, although I took some more time to fix the pile of SQL injection flaws still hiding around (PDO lets you protect yourself... nothing will protect you if you're concatenating user input into a query without even escaping it).

Anyone who is willing to let the dropping of the mysql_ API stop them from updating, isn't secure anyways.

Re:PHP 5.6

[xonen]

It takes hardly an hour to write a decent PDO wrapper that provides the old mysql interface.

Been there, done that, but there's a (big) performance penalty doing so.

The old mysql* interface was fine, functional and elegant in itself, the issues mostly because people not knowing how to use it correctly (being spoiled by all needless OOPS a.k.a. object oriented spaghetti) , and not because of a significant limitation of the api itself.

Writing a wrapper sort-of works but is never 100% optimal, plus the whole website needs to be evaluated. Rewriting *everything* is simply out of the question for the obvious reasons and usually only leads to more and new bugs or new security issues.

Breaking what's not broken in the sake of 'security' instead of directing people to RTFM is just ignorant. I totally agree with GP.

Re:Not surprising

[cute-boy]

Lots of enterprises rely on RHEL 7 / CentOS 7, and those are currently shipping PHP 5.4.16.

And if you stay up to date, they are patched (but frequently lacking newer features), at least for RHEL. The Package Versions - Why our package versions are (almost) never bumped up?.

Re:Not surprising

[93 Escort Wagon]

And if you stay up to date, they are patched (but frequently lacking newer features), at least for RHEL.

Oh yeah, I didn't mean to imply otherwise (FWIW we're a CentOS 7 shop). But it would still show up as "PHP 5" on a survey - which might say as much about the limited usefulness of stories like this one as it does about anything else.

Re:5 and, but no mention of PHP 6

[gman003]

PHP 6 was never actually released.

PHP 6's main feature was better Unicode support... via UTF-16, which it turns out is an awful idea. It's still variable-length, so you get all that complexity just like UTF-8, but it's hugely wasteful in comparison to UTF-8 on stuff like HTML (outputting is literally the main purpose of PHP), and it adds some byte-endianness problems. After realizing it was going to tank performance and just cause more and more problems to develop, the other features were stripped out and ported back to PHP5. PHP7 was a separate project, focused on a new engine for much better performance (though it also added some much-needed syntax like typed parameters and null coalescing). They decided to just skip PHP6 because there was so much published material talking about it, but the main feature of it never appeared (PHP7 internally uses UTF-8 for strings).

PHP 7 is a non-trivial update, for some

[LostOne]

There is a *lot* of code out there that does questionable stuff in PHP. Stuff that approximately works in PHP 5.6 but fails hard in PHP 7. A large amount of it is relying on things that were deprecated way before PHP 5.6 was even considered as a possibility. A lot of that code is non-trivial so it isn't a quick fix to update it, or worse, is orphaned and there is nobody to update it.

Even worse, a large fraction of it is on sites who don't have a programmer. It exists in unmaintained modules or add-ons to some framework or other that is, itself, often never upgraded. At $dayjob, I've lost count of the number of web sites that get defaced because someone bought a web site from $random_web_developer who used $framework and then never did any maintenance. I mean, people still expect a web site to be "fire and forget", especially if it's a simple brochure style site, and don't understand why they should have to put resources into maintaining it. And they're not wrong, either. These are the vast majority of the sites I can't force-upgrade to PHP 7 without having the customers simply cancel their accounts and not pay their outstanding bills. (Eventually I'll have to, but not today.)

On the other hand, I had almost no issues running PHP code I wrote on PHP 7. But that's probably because I don't overcomplicated the code with eleventy thousand classes, namespaces, autoloading classes, "Composer", or any other fancy gimmick that is all the rage today. The issues I did have tended to be due to code that really shouldn't have worked in the first place, or actually wasn't working properly even on PHP 5.6.

Re:Can we get some "fractal of bad design" links?

[tepples]

Enjoy Fractal, Hardly, and a synthesis of the two by analogy to Douglas Crockford's JavaScript: The Good Parts

Re: Surprise

[dgatwood]

At least the MySQL stuff has a valid reason. The old functions were hard to use in ways that didn't introduce security bugs. Non-parameterized SQL queries are one of the most common causes of security holes, largely because they're really hard to get right. I'm all in favor of killing them. With fire.

It's the other thirteen pages of changes from PHP 5 to PHP 7 that are the problem — little, subtle things where variables get populated in the opposite order depending on what version of PHP you're running, or the order of operations changes in ways that require new parentheses. These sorts of changes are hard to spot in large code bases, and could potentially result in unexplained failures. If your code doesn't have amazing unit test coverage (which PHP usually doesn't)... good luck.

Re:PHP 7 is awesome

[infolation]

It still looks like a clusterfuck to me, although maybe slightly more unfucked than the last one.

Regrettably $CLUSTER_FUCK is a superglobal.

Re:5 and, but no mention of PHP 6

[hcs_$reboot]

PHP 6 was released along with iPhone 9.

Re:5 and, but no mention of PHP 6

[bobby]

php 6 was only supported on Windows 9.