A computer system or application needs to be patched regularly to keep it secure against vulnerabilities. Patches are typically provided by the OS vendor, and are typically applied using a standard utility such as "apt" or "yum" or "dnf". Unfortunately, operating system and application vendors only provide patches for a certain period of time. Beyond that, the software is said to be "end of life", meaning that security patches may no longer be provided through normal channels.
In the case of PHP, an number of older versions have already reached end-of-life (EOL), or will do at the end of 2018. Specifically:
- PHP 5.4 official security patches ended in September 2015
- PHP 5.5 official security patches ended in July 2016
- PHP 5.6 official security patches will end in December 2018
- PHP 7.0 official security patches will end in December 2018
In the case of CentOS 6, CentOS 7 and Scientific Linux, the OS distribution maintainers are backporting fixes for security issues into the last EOL'd verson of PHP for their platform.
You can also get into trouble with a non-EOL'ed versions of PHP if you do not keep up to date with applying security patches.
If your are running a NeCTAR instance with an unpatched version of PHP, your website is potentially vulnerable to a number of critical PHP security vulnerabilities. These could lead to your website being taken over, and used for various illegal and/or undesirable purposes.
Our vulnerability scanner detects a server's PHP version by examining specific header fields in HTTP / HTTPS responses from the server. Unfortunately, the reported version numbers are not a reliable indication of a servers vulnerability status. When security fixes are backported into older versions of PHP, the vendors typically don't change the PHP version number. For example, a freshly installed / updated PHP 5.4.16 installation on CentOS 7 has a number of years of backported security patches. Thus, when our scanner detects an instance with an installation of an end-of-lifed version of PHP, it is unclear if the installation is vulnerable or not.
In short: this alert could be a false alarm if you are running CentOS 6, CentOS 7 or Scientific Linux 7.
To be sure, you need to login to the instance and use the "apt", "yum" or "dnf" command to query your system's installed package version for PHP. Then you need to check via other sources to see if the installed PHP version is secure. Note that:
- More specific version indications are available from the package manager; e.g. the package version, release timestamp.
- You can typically get clues about which vulnerabilities have been fixed by looking at the package changelog for the installed package/
First, you should find out which version of PHP you are actually running; see above. Once you have determined that there is a problem, there are a couple of approaches to dealing with it:
- If you are running Ubuntu, Debian or Fedora, you should upgrade your system to a later (non-EOL'ed) version of PHP, and then apply OS security patches. Unfortunately, this is not an option with CentOS and Scientific Linux.
- If you are using CentOS or Scientific Linux, keeping the system up-to-date (using "yum") may be sufficient. This is contingent on the OS vendor continuing to backport patches into the last end-of-lifed release.
- There is a popular 3rd-party repository of RPMs for PHP at https://rpms.remirepo.net which provides up to date RPMs for RHEL / CentOS / Scentific Linux versions 6 and 7, and for Fedora Linux. Coverage is PHP 5.4 onwards.
Note: It is always advisable to apply all vendor security patches.