As PHP Group Patches High-Risk Bugs, 62% of Sites Still Use PHP 5 (threatpost.com) 112
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."
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."
Re: (Score:2)
Is that a reference to magic quotes? :)
Re: (Score:3)
Enjoy Fractal [eev.ee], Hardly [devshed.com], and a synthesis of the two [pineight.com] by analogy to Douglas Crockford's JavaScript: The Good Parts
5 and, but no mention of PHP 6 (Score:2)
Was version 6 utterly shite, or can't they even count?
Re: (Score:3)
yes
Re: (Score:1)
Not sure if you're just having a simple go at trolling, but PHP 6 never happened - the fundamental design was never completed and instead most of the ideas were formalized for PHP 7.
Re: (Score:3, Funny)
Besides, normally even numbers are used for stable releases. Why would PHP ever be considered dependable or trustworthy as a stable runtime?
Re:5 and, but no mention of PHP 6 (Score:5, Informative)
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).
Re: (Score:2)
Really, while that is a rather wordy way of saying 'so utterly shite it never made it out the door,' it is quite interesting to know how and why it was so bad. Thank you!
Re:5 and, but no mention of PHP 6 (Score:4, Funny)
Re: (Score:2)
php 6 was only supported on Windows 9.
Re: (Score:2)
Except the warnings of impending deprecation have been around for a while. For example, the old mysql family of functions (replaced w/ mysqli and/or PDO) started throwing E_DEPRECATED in PHP 5.5 which was released in mid 2013.
Re: (Score:3)
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 ru
Re: Surprise (Score:2)
Then you need to find a programmer that can understand how to fix that. It's often the case that the person who wrote it has exited the company a long time ago.
That's why breaking backwards compatibility is bad, especially on script based languages.
Not surprising (Score:2)
Lots of enterprises rely on RHEL 7 / CentOS 7, and those are currently shipping PHP 5.4.16.
Re: (Score:3)
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? [redhat.com].
Re: (Score:3)
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: (Score:2)
RHEL/CentOS 6 ships PHP 5.3.3. But one of the things that you get by using something like RedHat is that they back-port bug fixes. Sure a newer version of PHP might be nice, but if the applications work with (a bug-fixed) 5.3.3 then what is the business case for upgrading ? If a later version really is wanted then it is available via Software Collections [softwarecollections.org].
Re: (Score:2)
PHP 5.6 (Score:5, Insightful)
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: (Score:1)
5.6 is a minor release. PHP 5.0 (first major series release) came out July 2004... and 7.0 came out almost 3 years ago. I've used PHP off and on since 2.0.... If memory serves me, there were major breaking changes between 2 and 3, a few breaking changes between 3 and 4, rare few breaking changes between 4 and 5 and rare few between 5 and 7. The main exceptions I can think of are around misguided features such as magic quotes which were rightly deprecated.
We have quite a lot of old code in production that
Re: (Score:2)
Yeah minor things like magic quotes and MySQL libraries. All mysql calls from PHP5 have to be changed to at least mysqli if not PDO which is a big difference if you have deep entanglements with your database.
Re: (Score:3)
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 ob
Re: (Score:3)
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 e
Re: (Score:2)
Both Perl and Ruby have implemented injection-proofing with a thing called tainted variables. You can't fix stupid but in many cases you can make old applications injection proof by simply cleaning the $_REQUEST array at the very beginning of your script.
Sure it isn't clean but it's cheaper than rewriting hundreds of lines of code and introducing weird bugs or having to write tests for an application that doesn't have them.
The PHP way of requiring spaghetti-code (OOM) in the middle of what's basically a scr
Re: (Score:2)
The tainted variables concept only works if you have functions that can actually clean them. AIUI, the old mysql_ API does not have that, and in fact cannot have that without breaking compatibility with old (MySQL 4.x) servers. The actual C-level API for MySQL changed, as did the network protocol. So they split it - mysql_ was kept around for compatibility, and mysqli_ was made to take advantage of the new features, like bound parameters which ACTUALLY solve the problem of tainted data by separating data an
Migrating to PHP 7.x isn't that big of a deal. (Score:2)
Replacing stuff from 5.x that doesn't work is nigh trivial. Then again, if you did your homework and didn't code crap, 5.x is perfectly safe.
Of course we all know that PHP is the favorite PL of many people who can't programm, so YMMV.
PHP 7 is a non-trivial update, for some (Score:5, Interesting)
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: (Score:2)
You will have almost no problems running your code under PHP 7 as long as your code is not crap. Specifically 7.1+.
The problem is, your code is probably crap and you just do not know it. The amount of bad code that is silently accepted in PHP 7.0 (and less) is just mind boggling.
This has always been the problem with PHP. PHP gives you the rope hang yourself, you just do not know you have hung yourself.
PHP is the only language that makes you wish you were using Perl.
Upgrade PHP using Ondrej's PPA (Score:2)
Your application may well work with PHP 7.x, or there may be a newer version of it that does work with the newer version. That is unless you have home grown code, or must run an older version.
If you are running Debian or Ubuntu, you can upgrade PHP to 7.2, using the following commands:
This works on Ubuntu 16.04 LTS, if you need to stay on that, and not having to upgrade to 18.04 LTS. The former is supported for a fe
Re: (Score:2)
no, in general it won't work, PHP 7 breaks backwards compatibility which is why this article has no point.
Languages that break backwards compatibility cause people to stay with older versions. Get used to it, the next decade belongs to PHP 5
Re: (Score:2)
While what you say is generally the case, it does not have to be.
For example, Drupal 6 was released in Feb 2018, that is more than a decade ago. It was End of Life on Feb 2016, after version 8 came out.
But that did not stop people from using it. Even the impending PHP version change did not deter some from making the necessary changes for Drupal 6 to run under PHP 7.2.
See for example this announcement [mydropwizard.com].
I am testing a Drupal 6 site now and it does run under PHP 7.2.
So, checking whether the package one uses ha
Re: (Score:2)
Drupal 6 was released Feb 2008 [drupal.org], so more than a decade ago.
Re: (Score:2)
Drupal 6 was released Feb 2008 [drupal.org], so more than a decade ago.
Re: (Score:2)
You picked the worst thing on the planet to support your position.
there are 41,500 Drupal modules out there. You think a money making company is going to risk breaking one of the many chosen out of that pile that run their sites by changing PHP major version? Not a chance in hell.
Anyway, less than 2 percent of web sites use Drupal, it's not the driving force behind PHP websites.
Re: (Score:2)
I am a Drupal contributor for the past 15 years, so I know Drupal pretty well.
As I mentioned before Drupal 6 (core) has been patched to fully work with PHP 7.2. There is a concerted effort to do the same for Drupal 7 [drupal.org].
Yesterday, I tried PHP 7.2 with 4 sites on two servers. One site is Drupal 6, the others are Drupal 7. They all worked without a single code change. One configuration statement had to be omitted, but that was it. The sites in question have the advantage of not being a victim of the open buffet [2bits.com]
Re: (Score:2)
I'm devops who has a few dozen drupal servers in the hundreds of servers I admin....
since PHP 5.x is supported and will have security patches, why would we bother to even test 7.x and hope the hundreds of modules we use would have something missed in the test? Answer, we won't, we'll use the modules that were written for PHP 5 with 5.
There is zero incentive to change, it's only risk with huge downside if something missed. Someday when security patches stop then it would be concern.
other languages
Re: (Score:2)
I thought it was obvious, and you knew, but here it is:
PHP 5.6 (the last release for 5.x) will be end of life by 31 Dec 2018 (that is 2 months from now).
PHP 7.0, which is the default version for Ubuntu 16.04 LTS, end of life 3 Dec 2018 (1 month from now).
See PHP supported versions [php.net].
Hence, PHP 7.2 is the current version with the most life left, and the need to upgrade to it.
A little more into the future: PHP 7.3 is
Re: (Score:2)
the paid distros have their own support schedule, php 5 is a part of them
Re: (Score:2)
I don't use paid distros.
I use Ubuntu 16.04 LTS for all my servers. There is still one client on 14.04 LTS even.
Hence the need to move. So far, no surprises.
same old (Score:2)
a publicly exposed language which has always had security issues,
clever websites - not
um, Joomla has (Score:2)
Re: um, Joomla has (Score:2)
Considering all the headaches that php gives I wouldn't use anything that is based on php.
Re: (Score:2)
Yes, php, a language that built sql injection vulnerabilities into the API.
At least they know what query parameters are now. The programmer wasn't entirely at fault, up until PDO anyway.
Re: (Score:2)
Re: (Score:2)
poor understanding of whatever scenario is the programmer
This. Shame with PHP though that between versions magic quotes crept in, so legacy programs that had to work around lack of parameters then had to be adapted to cope with systems where a new layer was introduced, otherwise things became double escaped.
Re: (Score:2)
It's open source, why not cherry pick the bits you want, and name it something else?
Re: (Score:1)
If enough people don't want to be force-fed 7, it could happen.
CentOS, etc. (Score:1)
Not quite as bad as it sounds (Score:2)
Re:PHP 7 is awesome (Score:4, Funny)
It still looks like a clusterfuck to me, although maybe slightly more unfucked than the last one.
Regrettably $CLUSTER_FUCK is a superglobal.
Re: PHP 7 is awesome (Score:2)
It might be, but the major reason for people not upgrading is that there are breaking changes between the major versions of php.
So you can't just drop in a new version because then something on your server breaks. And anyone that knows that piece of code has long ago left for greener pastures. It's usually some medium sized package that just do the job and is key for the business.
Php is also a headache from a test perspective since you don't find the broken stuff until you try to access it. Some of it may o
Re: (Score:1)
There are tools to check your code to see if it will work with newer versions of PHP, like PHPCompatibility.
Any testing PHP is easy : you can write unit tests, integration tests, etc.
Re: (Score:2)
The problem is still that you have to get someone that can care for the code. It's a common problem - hire someone to do a specific job and then when that person leaves there's just something that works, but it happens to block upgrades also for other applications.
Just come out to the reality and see - the world is full of small solutions that happens to be blocking upgrades of larger application suites. And the management of the companies don't want to upgrade "because it works" and that they don't want to
Re: (Score:1)
Oh believe me, I know ;-)
Managers don't understand that any piece of software needs maintenance...