Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
PHP Programming Security IT

As PHP 5.6, Still Used By a Large Number of Websites, Approaches Its End of Life Deadline, Some Worry About the Consequences (linkedin.com) 151

Posted by msmash from the ticking-time-bomb dept.
An anonymous reader writes: I know PHP isn't to some devs liking, but chances are you know people who work with PHP or have sites that are built with it. PHP 5.6 and 7.0 are shortly coming to the end of the support period for security patches, so what plans have you made to migrate code and sites to newer platforms? With apparently huge numbers (80%) of sites still running PHP 5.6, there appears to be little industry acknowledgement of the issue. Is there a ticking PHP Time Bomb waiting to go off?
This discussion has been archived. No new comments can be posted.

As PHP 5.6, Still Used By a Large Number of Websites, Approaches Its End of Life Deadline, Some Worry About the Consequences More

As PHP 5.6, Still Used By a Large Number of Websites, Approaches Its End of Life Deadline, Some Worry About the Consequences

Comments Filter:

  • Wow, PHP 5.6 has been around for how long?

    • Re: (Score:2)

      by zidium ( 2550286 )

      Your website (www.aisnota.com) is down. Did you have problems upgrading to PHP 7.2??

  • Not just 5.6 (Score:5, Interesting)

    by Ubi_NL ( 313657 ) <joris.benschopNO@SPAMgmail.com> on Thursday August 23, 2018 @10:35AM (#57180322) Journal

    The current RedHat 7 ships PHP5.4 (or lower) by default. Adding 5.6 means adding a non-standard repo and thus tainting your update environment. Can be done but not classy.

    Having said that, I run a small ISP with many tiny NGOs as customers. All these sites were developed for PHP5.2 or something by "Bob" who left and nobody has the money or expertise to update the site to PHP5.6 or higher. If I force an upgrade I effectively kill over 300 websites that are pretty much running fine, despite the vulnerabilities puslished. Remember that most of these customers have ever even heard of PHP or what it is supposed to be doing, and they care even less as they are not IT people.

    • Re: (Score:1)

      by Anonymous Coward

      Remember that most of these customers have ever even heard of PHP or what it is supposed to be doing, and they care even less as they are not IT people.

      We wouldn't accept that excuse from anyone else who handles dangerous tools. A public facing website comes with responsibilities. If they can't or don't want to deal with the security implications of running a PHP website, then they shouldn't be running a PHP website. I specifically recommend static websites (with embedded externally maintained active elements, if necessary) to people whom I do not expect to be able or willing to maintain an active website. You can't have a dog if you won't feed it and clea

    • This is both a problem and a rare quality of the language. Even clueless people are able to get some decent output off of PHP.

    • Re: (Score:1)

      by Anonymous Coward

      Almost none of what you said is true. Red Hat provides several newer versions of PHP in the Software Collections repository; it's not a default repo, but it is certain not a "non-standard" repo as Red Hat absolutely provides support and on-going patches for it.

      And running a web server on an app with known exploits in the wild means you are not running "fine", you are running only until some hacker or script kiddie notices your website and decides to see how much fun they can have with it.

      As far as custome

      • Re: (Score:3)

        by Junta ( 36770 )

        Well, software collections can be a pain... A lot of things just aren't that effortless if you have to go that way.

        However, even as upstream declares the end, redhat does continue to support the older language, backporting fixes and supporting it beyond what upstream commits to.

        This is actually one of the big conundrums for RedHat. In order to have the resources to provide very long term support, they have to be relatively choosy about how much and how frequently they support upstream changes. As a resul

    • Re: (Score:1)

      by Anonymous Coward

      The code isn't "running fine" if it's a ticking time bomb any more than using a charcoal grill inside of an apartment is "fine" as long as the resident promises not to spill hot coals on the carpet.

      Help your NGO customers find some volunteers at a local university if that's what it takes to get them to update their code. But ultimately, it's your space and you're going to have to assert your authority over it for your own good and for the good of everyone who uses that space.

      • Everything related to computers is a ticking time bomb. Hell, even Intel, AMD and others have security flaws in their fucking processors. And you expect people who write websites to be security experts?

      • Sometimes if they just put up a warning flag, that is enough to keep the resident aware of the issue.

        Sometimes code that is considered "just a matter of time" never reaches such time. Because there is so much effort around avoiding it.

    • Here is the core of the problem that many organizations don't understand or appreciate-- building a web application is an ongoing process, not a one-time-deal. Of course it doesn't help that PHP is a frustrating language when debugging someone else's code.

    • Re: (Score:2)

      by c0p0n ( 770852 )

      Many of the vulnerabilities that have gone unpatched since 5.2 allow for remote code execution on the servers you're responsible for and perhaps sharing with different customers.

      • I hear people say things like that from time to time, but where are the real-world attacks? It seems like it is far more likely for people to get hit by vulnerabilities in PHP applications like Wordpress or Drupal than the language itself.

        • Re: (Score:2)

          by c0p0n ( 770852 )

          That might be so, but the danger remains. It's not a problem until it is.

          • I'm just suggesting it is not an actual danger. If there is no way to actually exploit it, and therefore no attacks, then it's not a danger. Conversely, if there was a vulnerability that allowed remote code execution in any web server running PHP 5.2, you can bet your ass it would be actively exploited (for the previous 12 years, no less). The lack of ongoing attacks of that nature would suggest that such a vulnerability does not exist, or at the minimum is not known.

            In other words, it sounds like FUD.

            • Re: (Score:2)

              by c0p0n ( 770852 )

              Only because you don't know about them doesn't mean they do not exist. Have a look in here:

              https://www.cvedetails.com/pro... [cvedetails.com]

              For instance these in 2017 https://www.cvedetails.com/vul... [cvedetails.com]

              The vast majority of these are for versions = 5.5, for obvious reasons as they've been EOL'd for years. Unless you're running some version of red hat that still patches their 5.4 installations, you're likely vulnerable to many of these.

              • I realize those are out there and known. I'm not talking about things that I don't personally know about, I'm talking about things that no one knows about.

                What I am saying is that there is a lack of attacks against PHP itself. Just having PHP installed is not a security threat. Proof of this is the complete lack of attacks against any arbitrary server running the world's most popular server-side language by number of servers, as far as I'm aware. The CVEs I have looked at all require scripts using speci

                • Re: (Score:2)

                  by c0p0n ( 770852 )

                  If that let's you sleep better at night, sure. Stuff isn't hacked until it is.

                  • Haha, well PHP CVEs certainly don't impact my sleep schedule. For example, I've never needed to use com_print_typeinfo, and it's not used in the framework that our application uses, and even if it did it probably wouldn't take user-supplied data as an argument, and even if it did our servers do not run Windows. So I don't need to worry about arbitrary code execution using this [nist.gov].

                    This is what I'm talking about. Yes, that vulnerability exists. But the vulnerability is not "run PHP and you're vulnerable to t

  • Explain That to Clients... (Score:5, Insightful)

    by michiganbob ( 1136651 ) on Thursday August 23, 2018 @10:38AM (#57180346)

    I know there are still sites out there that run on PHP 5.6 (and earlier!) that should really be moved on, either updated for PHP 7.2 or if the code is unmaintainable due to years of abuse by developers, simply rebuilt in a modern framework.

    Sure, let me just go back to the hundreds of small businesses we've built websites for over the past 10 years and tell them their sites need to be "simply rebuilt". I promise you that 95% of them will see no problem with leaving their PHP 5.6, 5.4, 5.2, etc... websites alone because "they still work fine". Why would they pay us money to rebuild them?

    The older websites probably have horrible looking admin interfaces making work flow slow and cumbersome...

    Maybe, but the site owners know how to use that admin interface, and getting them to that point was like pulling teeth. Now you want to train them on a brand new interface? Good luck.

    I'm not saying this guy doesn't have some points, just that he doesn't seem to live in the real world.

    • I know there are still sites out there that run on PHP 5.6 (and earlier!) that should really be moved on, either updated for PHP 7.2 or if the code is unmaintainable due to years of abuse by developers, simply rebuilt in a modern framework.

      Sure, let me just go back to the hundreds of small businesses we've built websites for over the past 10 years and tell them their sites need to be "simply rebuilt". I promise you that 95% of them will see no problem with leaving their PHP 5.6, 5.4, 5.2, etc... websites alone because "they still work fine". Why would they pay us money to rebuild them?

      The older websites probably have horrible looking admin interfaces making work flow slow and cumbersome...

      Maybe, but the site owners know how to use that admin interface, and getting them to that point was like pulling teeth. Now you want to train them on a brand new interface? Good luck.

      I'm not saying this guy doesn't have some points, just that he doesn't seem to live in the real world.

      We have some clients like that. What can you do? We just explain the risks, and if they want to take them, that's their look out. Some of them are even willing to spring for something like Sucuri firewall as a stopgap rather than upgrade anything.

      Eventually the hosting company itself will force a PHP upgrade (and their site may or may not stop working, but it will be unplanned). Or they will get hacked first. Either way, it's on with the game face, try not to say "I told you so" (unless they try to blame i

      • Re: (Score:2)

        by c0p0n ( 770852 )

        Not much more you can do other than that tbh. Explain what they're exposing themselves to, and let them make a choice.

        Sites in php 5 are easily migratable to 7.x, obviously the earlier the version the less "easily". The vast majority of 5.6 code should run on 7.x with no issues. They did a pretty good job at avoiding big bc breaks.

    • Well you should had insisted on some sort of support contract. Software is never done, and if they didn't pay for support, and the prereqs become volnerable. Then it is up to the customer who cheeped out.

      • Re: (Score:1)

        by Anonymous Coward

        Software is never done...

        If something's never done, how do you expect to get paid? That's the whole point. Most websites that are not SaaS plugs are produced as works for hire. When they are complete you get paid. Sure, you can talk about ongoing support and maintenance after that, but you're generally free and licensed to walk off with it at that point, which many do. How software works in the real world.

    • I'm not saying this guy doesn't have some points, just that he doesn't seem to live in the real world.

      I am reminded of a saying that goes something like this: In theory, theory and reality match. In reality, they don't.

  • Who set arbitrary support deadlines for popular software like Windows XP. Just keep support going like like Cobol programs.

    • And who do you propose do the work to support said software? The PHP folk 'only' support the last three major versions. Which will be 7.1, 7.2, and 7.3 come December. Support for 5.6 had already been extended for an extra year.

  • favor evolution over revolution! (Score:3)

    by kiviQr ( 3443687 ) on Thursday August 23, 2018 @10:56AM (#57180472)
    Frameworks, languages should always provide a clear migration path and never jump major versions. Python, Zope, PHP, and many more learned that lesson in a hard way.

    • Frameworks, languages should always provide a clear migration path and never jump major versions. Python, Zope, PHP, and many more learned that lesson in a hard way.

      PHP has been deprecating things and giving warnings for years.

      • Re: (Score:2)

        by kiviQr ( 3443687 )
        You have to play your users - it is a mind game. Deprication warnings are great but them jump 5 to 7 is a problem. People will upgrade to next minor version but will hesitate a move to major version (not to mention 2 major versions). You need to move users thru small set of changes in each minor release 5.7, 5.8, 5.9, then 6.0. It takes more time and planning but it ensures everone moves along. The only way to fix it is to release 5.7 branch and start including 7.0 changes.
      • Comment removed based on user account deletion
  • My ISP applies a support charge to any websites that don't run the latest version, whether that's PHP or MySQL. It's an incentive to upgrade, and it would be interesting to find out how many just accept the charge versus those who upgrade or pull their sites entirely. It certainly encouraged me to ditch a few websites I was half-hearted about.

  • When your cloud provider only provides images for OS's that are two years or more out of date, and your OS vendor only provides packages for 4 year old versions of software, this is what happens.

    It's even worse

  • We've been upgrading sites to PHP 7+ for awhile now.

    Haven't been too many issues, as long as the CMS is reasonably up to date. When issues do arise, it's usually some old theme/template with too much functionality stuffed into it, or some obscure CMS plugin/addon.

    The only constant is change itself, and all that ... hasn't been a huge deal.

  • Version [Insert Version] of [Insert Coding Language Here] is a ticking time BOMB! Support for critical patches ends on [Insert Date Here] leaving customers with buggy and unpatched software which will be exploitable.

    ------
    There, that should work as a template. Seriously, all software that is not actively maintained is at risk (and honestly all software being maintained has a certain level of risk to it as well). If I remember correctly you have reached the end of the software life cycle when there are no

  • Honestly, most websites can run on PHP 7.2 by adding error_reporting(E_NONE);

    • Re:error_reporting (Score:5, Interesting)

      by eriks ( 31863 ) on Thursday August 23, 2018 @12:27PM (#57181138)

      That's true, unless the code uses the (LONG deprecated) mysql_* functions. Though even that is actually trivial to fix, since PHP7 supports built-in function overloading, and since good code will abstract database calls anyway, even switching to one of the newer DB methods should be pretty straightforward.

      I maintain code that was actually written for PHP3/4. Migrating to PHP5 was frustrating, mostly because some of the the breaking changes involved REALLY basic stuff (they broke array indexing!), and weren't rolled out with the first version of PHP5, but came out in dribs and drabs in the point releases. Migrating to PHP7 is really not that bad by comparison, and PHP7 fixes most of the really bad warts in the language.

      Granted this code was originally written almost exclusively by me, and I was/am a Perl/C programmer so the code looks more like C-style Perl than most PHP code.

      PHP3 was *nasty* and I went into the project kicking and screaming, but I was part of a team that outvoted me. I wanted to write the thing in Perl. Almost 20 years later, the code still works, is maintainable/customizable, and the language itself is much less nasty than it was then.

    • I hope you're not seriously suggesting that ignoring errors is a solution.

  • redhat / centos needs up the version numbers. The backpacking is ok but why not up them when they do 7.2 7.3 7.4 7.5 etc.

  • Forgive my shadenfreude, but I recently ran a deployment that among other things did "service apache stop". No more PHP. In our case, all of our web APIs are now entirely python-based (python flask + uwsgi + nginx). So I'm happy to be able to say I no longer care about PHP one way or the other... not that it's true, I still think it's a horrifically bad language with incredibly bad everything-around-it (documentation, libraries, frameworks, ugh..)

    • Many keep saying Python is a notably better language than PHP, but most the time one is just calling API's and frameworks. One is not typically dealing heavily with core language aspects anyhow for run-of-the-mill CRUD and commerce apps. Or am I missing something? Thus a "better" core language doesn't mean much in practice. Other factors overshadow the difference.

      Plus, PHP comes with more web-oriented libraries and features, because Python is designed to be a "general purpose" language, not a web language.

      • Many keep saying Python is a notably better language than PHP, but most the time one is just calling API's and frameworks. One is not typically dealing heavily with core language aspects anyhow for run-of-the-mill CRUD and commerce apps. Or am I missing something? Thus a "better" core language doesn't mean much in practice. Other factors overshadow the difference.

        That would be a good point, except that a lot of the libraries of PHP are just as terribly designed as the core language. Especially the standard library of PHP is like an all-you-can-eat buffet of assorted bad practices. If you look at the famous article on just how bad PHP is (https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/) there's a whole section on just how awful the standard library is.

        Plus, PHP comes with more web-oriented libraries and features, because Python is designed to be a "general purpose" language, not a web language. You can attach libraries to get Python more webby, but that often creates more dependencies than using the built in ones.

        I'm not sure what being "webby" even means. Yes, you'll probably end up using some libraries outside of t

        • Re: (Score:1)

          by Tablizer ( 95088 )

          Re "fractally bad", all languages and non-trivial libraries have screwy annoyances, and sometimes bugs. You learn what they are and work around them.

  • Unless the interpreter expires!

  • Numbers could be betters if there were no backward incompatible change. Take the mysql module for instance, it would not have been difficult to provide it as a compatibility layer on top of mysqli. Same for apc and apcu.

    Of course code can be migrated, but anything that increase the difficulty makes it more likely that an upgrade will not happen.

Slashdot Top Deals

"The vast majority of successful major crimes against property are perpetrated by individuals abusing positions of trust." -- Lawrence Dalzell

Close