Backporting security updates in Enterprise Linux

Backporting is the task of taking a bugfix from the latest version of an upstream software package and applying that fix to an older version of the same software. It is part of the preservation step in the application development process, and is sometimes used to add new features to older versions of software.

Backporting is common among vendors such as Red Hat^® and is necessary to ensure automatic system updates. There’s a possibility to make use of backported patches in EuroLinux 8 from its source code vendor, that is Red Hat^®.

The backporting process can be divided to the following steps:

identification of a problem in an older software version, that needs to be fixed with a backport
determining, which code modification make the problem go away
applying that modification to an older version of code (proper backporting)
testing if the backported version has the earlier functionality preserved and if it implements the new functionality correctly (one or more quality assurance levels)
merging a few of such modifications to a set of patches

Why security updates are being backported?

Here is a practical historical example that illustrates and explains this point well:

Red Hat^® made PHP version 5.3 available on Red Hat^® Enterprise Linux 6. PHP version 5.3 reached end-of-life on August 14, 2014, meaning that no additional patches or enhancements were provided by upstream for this version. However, on October 14, 2014, a buffer overflow vulnerability CVE-2014-3670 was discovered in all versions of PHP, marked as Important (we have described severity rating in this article), that allows a remote attacker to corrupt a PHP application or execute arbitrary code with the privileges of the user running that PHP application.

Since version 5.3 of PHP has been retired, a fix for this bug was not provided in the PHP 5.3 release. The only way to minimize this issue was to upgrade to PHP 5.4, which included a fix for CVE-2014-3670. However, Red Hat^® customers using PHP 5.3 may not have been able to migrate to PHP 5.4 because of possible backward compatibility issues between versions 5.3 and 5.4. The migration process would require manual work by system administrators or developers. For this reason, Red Hat^® has backported a fix for this bug into the PHP 5.3 packages shipped with Red Hat^® Enterprise Linux 6 so that customers could continue to use PHP 5.3 while mitigating the impact of CVE-2014-3670.

RPM packages versioning

RPM packages distributed in Red Hat^® or EuroLinux have a certain consistent naming convention. Let’s take the Tar package as an example. To get this information we need to run the command: rpm -q tar.

Name: Software name – in this case it’s the tar program.

Version: Version of the Open Source project used to create this package – in this case the package is based on the version 1.30 of GNU Tar.

Additional version: This piece of information on the package version is specific to Red Hat^® and/or EuroLinux. Usually an RPM provides this field so a packager can preserve their data on a package version. Different package maintainers or teams can format it in a slightly different way. Usually this field also contains the EuroLinux version, for which the package has been created. With the rpm -q --changelog command one can display detailed information on new functionality, applied patches or backports added to a specific additional version.

Architecture: Type of a CPU, for which binaries in a package have been compiled. This field has distinct CPU architectures visible if binaries have been compiled for a different CPU (e.g. aarch64) or noarch, meaning that a package is architecture-neutral.

Uncertainties about versioning

Backporting has its advantages but can cause a commotion if not understood well. Customers should be aware that the package version number alone will not tell them whether they are vulnerable to attacks or not. For example: news articles may contain messages similar to “upgrade Apache httpd to version 2.4.48 to fix a bug” that only take into account the upstream version number. So even after installing the updated packages from the vendor, customers will not have the latest upstream version. Instead, they will have an older version, but with the correct fixes that were applied in the older versioning.

In addition, some security scanning and auditing tools make vulnerability decisions based solely on the version number of the components they find on the system. This results in false positives because these tools do not take into account security fixes for packages that have been retired from upstream.

Package vendors try to explain in security bulletins how a particular vulnerability was fixed, either by moving to a new version or by backporting fixes to an existing version. Since January 2000, CVE names have been included with all bulletins so that customers can easily compare vulnerabilities and find out how and when they were fixed, regardless of version numbers.

OVAL definitions, that is machine-readable versions of the bulletins, are also being provided. These can be used by third-party tools to determine the status of vulnerabilities, even if the fixes were placed in earlier versions of the software. This manages to eliminate some of the confusion associated with backporting and makes it easier for customers to “stay up-to-date” with the latest security patches.

More than security

For most Red Hat^® products, the default practice is to backport security patches, but occasionally additional version updates are made available for certain packages after careful testing and analysis. These are versions that do not interact with other packages or those that are frequently used by end users, such as web browsers or instant messengers.

Red Hat^® support also includes backporting of kernel modules from newer Linux kernels. This means that newer hardware is supported by Red Hat^® and EuroLinux systems even when using older kernel versions. All of these solutions make Enterprise Linux systems stable, secure and continuously modern. And that’s why they are so eagerly chosen by corporate customers.