Security risks of running a php application on PHP 5.4

Question

I'm a senior developer maintaining a FinTech SAAS web application. The web application is currently running on Fat Free Framework on PHP 5.4 on a LAMP stack. I've been instructed that it has not been upgraded because upgrading to 5.6 would cause issues with our authentication plugin (BCRYPT).

I am aware that PHP 5.4 reached its EOL on 3 Sep 2015 which included ending security support. Similarly, I am aware that PHP 5.6 will reach its EOL Dec 2018 and will lose its security support as well. We have also recently completed a web application security audit with a 3rd party contractor. Oddly enough this information regarding the PHP versions was not included in the draft report --which I was expecting to see. I intend to bring this up with them following presidents' day.

To be clear. I have raised the 5.6 EOL to my CTO, but have not raised the 5.4 EOL issue yet (more on that later). Originally I was not aware of it until I expressly checked it following its omission in the draft report. I have recommended we upgrade out of PHP 5.x because of the security risk involved; however, my CTO has rejected this thrice: ostensibly because it'd take to long and/or prioritizing new features promised to clients.

I intend to bring this up a 4th and final time, but wish to do so armed with tangible information on the risks involved. The answers to my question below will be included as well as points raised when I discuss this with my security auditor.

So with respect to risk management what are the distinct risks of continuing to support this application with PHP 5.4 and/or PHP 5.6?

Note: I am well aware that this is a security risk, but I don't know specifically why. I am developer not a security specialist. As such, I would greatly appreciate detailed answers . Inclusion of known unpatched exploits that affect FFF or PHP 5.4 would also be appreciated. If there's a website that supplies such information even better.

Answer 1

Rule one: cover your ass: make sure you've got an offsite record of you reporting a security risk to your CTO and their response.

Beyond that, if their is a risk that the upgrade will break authentication, then the first step is to characterize that risk. I am aware of changes in the blowfish implementation of crypt in 5.3.7 - but those are backwardly compatible and you're currently on 5.4

The most important thing you can to do to ensure the Security of your applications is to keep your patches up to date. In 2015 and 2016 US-CERT advised that 85% of compromises were preventable (by applying patches). The Equifax compromise of 2017 was a result of unpatched software on a web facing application. You don't have to look far to find more examples.

Listing the current vulnerabilities in your stack does not really help with the problem - you should have processes in place to keep your software up to date. You don't need to enumerate the currently known vulnerabilities.

It is reasonable to make a decision not to patch if the organization can prove that the resulting losses would be significantly less than the cost of updating. But has that analysis actually been done?

While you could choose to go around your CTO to the owner/stakeholder, unless this a publicly listed company, they are unlikely to understand your concerns or favour your version of events over that of the CTO. Any competent organization should maintain a risk register - you should document your understanding of the current situation, the danger of being in a situation where you cannot easily upgrade and request that this is added to the corporate risk register.

Answer 2

I'm with your CTO.

The changelogs for PHP 5 and FFF:

https://secure.php.net/ChangeLog-5.php
https://github.com/bcosca/fatfree/issues?utf8=%E2%9C%93&q=is%3Aissue+security

have much in them to excite an attacker/red teamer. But it's never that simple.

Performing a one-off platform and framework upgrade will likely have very little impact on the overall security posture of your application.

Of course- patching attacker visible endpoints and keeping current on application level dependencies are important/critical organizational habits. But they need to be habits, not projects.

Treating them as projects is like going on a crash diet. Three to six months later- you're back in the same place.

I recommend a different course of action. Two actions:

1. document a threat model for your application
2. document a plan to defend the threat model by focusing on the lines of code and configuration that you are responsible for, such that these can be weighed against similar defenses executed via platform or infrastructure upgrades

A threat model is just a fancy term for documenting in plain language:

• what your application does, in the context of your business and industry
• of the features and functions it offers, which are sensitive (and why, and to whom) and which are not
• what kind of attackers would be interested in the sensitive bits
• what protections currently exist to notice or defend against those attackers
• what mitigations exist for what kinds of compromises (insurance, etc)

Perhaps you already have something like a threat model from the web app security audit, though that's more likely just a laundry list of deficiencies, not something that looks at the application in the ecosystem context. Deficiency lists are not that helpful because every single platform is exploitable, given enough time, resources, and attention. Even high risk scores are generic, not necessarily applicable to any particular situation.

The most important defenses to focus on, given one's own limited time and attention, are those that address the areas of greatest risk to your org that your application has functional responsibility for. This prioritization should come from a threat model.

As the maintainer, you know what the application does, and you probably know the ecosystem context. You probably have a sense of which features/functions/data are sensitive and which are not. You may not have the full context, but that's an important area to build understanding of. You probably don't know what kinds of attackers might be interested in what kinds of exposure, what protections currently exist at other layers of the tech stack, and what organization-level mitigations exist. (Every org has a laundry list of "known risks." Don't defense against something considered to be a known risk).

In any area you should be able to learn what you don't already know from relatively short conversations with your security team and/or others in your org's hierarchy. A first-pass document summarizing these learnings should not be more than 2 pages.

Once you have a threat model that finds threats for which there may be insufficient mitigation, proposals to mitigate either with application code changes or through other approaches (like platform upgrades) can be weighed against one another on cost and effectiveness. And now you are talking your CTO's language.

After going through these two steps, you may arrive at a place where a one-off project to upgrade PHP and FFF, given the difficulty (PHP 5 updates are not fun), lands no higher than 4th or 5th on the list of security priorities. That's ok. A better project is to build the automation that allows keeping up-to-date to be a habit.

Hope that's helpful, though perhaps not the answer you're looking for. Good luck.