Manaslu's picture

Hi Jeremy,

i hope you are well and safe. i have a quick question. As upgrading the PHP version is not recommended within the turnkey appliances, how about the build from 29 to 33? We are using wordpress turnkey appliance v16 and due to the following Vulnerability: PHP XML Special Character Processing (N21-773) in 29, we want to update the build.

Will this patch fall under the security updates that is pushed regularly or there is a way i can do that manually?

Thanks in advance



Jeremy Davis's picture

In an effort to clarify further, you can not just check the version to know whether a security vulnerability applies or not. Generally, the fixes for security issues are backported to the exact same upstream version (the debian version will get an update like 'debian10u1'), although in some more complex cases, a slightly newer version may be imported (if that's easier and the risk of regressions are low).

To answer your question regarding a specific vulnerability, we need to know the CVE code of the vulnerability. 'N21-773' doesn't seem to relate to any specific PHP vulnerability that I could find? Looking at the php7.3.33 changelog though, I see reference to "XML: Fixed bug #79971 (special character is breaking the path in xml function). (CVE-2021-21707)".

Assuming that CVE-2021-21707 is the vulnerability you are referring to, then you can check the Debian security tracker by going directly to the URL:

As you can see there, it hasn't yet been fixed in any release (other than in unstable/Sid - by virtue of that having a bleeding edge PHP version). It's been tagged as a minor issue and won't receive a patch until the next time they push out a PHP security update (either once they have a few issues to fix, or a high priority issue needs fixing). It seems reasonable to me that the Debian security team are correct to label it minor, when you consider that it was first reported to PHP back in August and they only just pushed out a fix mid November (after mulling over whether it was even a security issue at all). I also note that neither Ubuntu nor Red Hat have patched it yet either.

Unless you have some specific reason to be concerned about that particular vulnerability, I would personally be inclined to just wait until the fix (via a Debian security update) is applied. If you do wish to update to a version that doesn't include that particular bug, then you'll need to install from a third party (as I'm sure I mentioned elsewhere). If you want specific details, please ask and I'll provide more details.

For future reference, you can view all the CVEs related to the PHP 7.3 package (both patched and unpatched) on the Debian security tracker PHP7.3 source package page.

Finally though, you note that you have PHP 7.3.29. Actually you should have 7.3.31! The version jump occurred in DSA-4993 (Debian Security Announcement - see also DSA-4993-1). DSA-4993 fixed CVE-2021-21703 (released mid Oct 2021).

You can check to see if you have that installed like this:

apt policy php7.3
Manaslu's picture

Thank you Jeremy for the detailed information. I would appreciate if you could provide me with detail information on the third party update process.



Jeremy Davis's picture

Ok so the repo to use is: There is a readme in the base of the repo which will assist you to set it up. Although, personally I prefer to do it slightly differently. This is what I would recommend on a v16.x server (all run as root):

wget -O /usr/share/keyrings/php.gpg
cat > /etc/apt/sources.list.d/php.list <<EOF
# DEB.SURY.ORG repo for php
deb [signed-by=/usr/share/keyrings/php.gpg] buster main

Then you should be able to run an "apt update" and "apt install ..." your desired packages. It's probably a wise idea to take stock of which php packages are installed, before you make any changes. This will write them to a file:

 apt list --installed | grep -i php > /root/default_php.txt

So now you can check that file (i.e. 'cat /root/default_php.txt') to work out which packages you will need in the alternate PHP version. Note that the list will include any packages that include php in the name (so may include non PHP packages that include php in the name - it should be zero, but just in case). You should be good to just install them via apt.

It's perhaps obvious to some, but I think it's worth noting that you'll need to ensure that the relevant php version of packages are installed. E.g. If you are upgrading to PHP7.4, then having "php-mysql" won't do what you expect, you'll actually need to install "php7.4-mysql".

For use with Apache, the all important thing is not just ensuring that you have installed the newer Apache mod_php (libapache2-mod-phpX.Y - where X.Y is the desired PHP version, e.g. libapache2-mod-php7.4) you'll also need to enable it. Assuming PHP7.4, do that like this:

a2dismod php7.3
a2enmod php7.4

Then restart Apache:

systemctl restart apache2

If you use PHP via commandline, then you'll also no doubt want to update that too:

update-alternatives --config php

That should list any available PHP versions and allow you to select the one that is used when you run 'php' from the commandline.

Note that if you have made tweaks to the PHP config, you'll need to reapply them to the new PHP config file (IIRC should be /etc/php/X.Y/apache2/php.ini or /etc/php/X.Y/cli/php.ini for Apache and CLI config respectively, where X.Y is the PHP version). The final thing that I can think of is updating the config file paths in Webmin (if you use it). I suggest that you replace the default paths with the new PHP config file paths. I don't recall exactly how to do that, but IIRC it's pretty straight forward.

Don't forget that once you do that, you'll no longer get the auto security updates for PHP. You'll continue to get other Debian OS sec updates, but will need to manually install any newer PHP updates. Note too that it's likely that most updates won't be security related, but there won't generally be anyway to tell (unless you read the changelog). The main reason why we recommend not auto installing anything other than security updates is because new releases can also bring new bugs (carefully backported fixes contain significantly less changes, so also less room for new bugs). So be sure to always have a current, tested backup (I recommend a snapshot if/when possible) ready just in case something goes wrong. I wouldn't anticipate any issues, but you can guarantee that if you skip taking a backup one day, that will be the day there a serious bug in a new PHP release!

Hopefully that gets you going. If you get stuck and/or have concerns or questions, please post back. Good luck.

Add new comment