on of an upstream software package and apply that fix to an older version of the package we distribute.
Backporting is common among vendors like Red Hat and is essential to ensuring we can deploy automated updates to customers with minimal risk. Backporting might be a new concept for those more familiar with proprietary software updates.
Here is an example of why we backport security fixes:
Red Hat shipped version 2.0.40 of the Apache HTTP Server with Red Hat Linux 8.0. Shortly after the release, a number of security issues were found and disclosed by the Apache Software Foundation. The Apache Software Foundation issued a new release, Apache HTTP Server 2.0.43, which contained fixes for those issues; however, in addition to the security fixes, a number of other changes (bug fixes and new features) were made between versions 2.0.40 and 2.0.43.
One of these features changed the module interface. In this case, if Red Hat issued a security update with version 2.0.43 of the Apache HTTP Server, replacing version 2.0.40, any modules customers were using would need to be updated (recompiled) to match the new module interface. If customers were using third-party modules, they would have had to go to their supplier of those modules to get updates. Moving from version 2.0.40 to 2.0.43 of the Apache HTTP Server would require manual effort by system administrators. Such an update would not be suitable for automated upgrade systems such as the Red Hat Network.
In cases like these, we can backport the updates. When we backport security fixes, we:
Also, some security scanning and auditing tools make decisions about vulnerabilities based solely on the version number of components they find. This results in false positives as the tools do not take into account backported security fixes.
Since the introduction of Red Hat Enterprise Linux, we have been careful to explain in our security advisories how we fixed an issue, whether by moving to a new upstream version or by backporting patches to the existing version. We have attached CVE names to all our advisories since January 2000, allowing customers to easily cross-reference vulnerabilities and find out how and when we fixed them, independent of version numbers.
We also supply OVAL definitions (machine-readable versions of our advisories) that third-party vulnerability tools can use to determine the status of vulnerabilities, even when security fixes have been backported. In doing this, we hope to remove some of the confusion surrounding backporting and make it easier for customers to always keep up to date with the latest security fixes.
http://gengwg.blogspot.com/
Backporting is common among vendors like Red Hat and is essential to ensuring we can deploy automated updates to customers with minimal risk. Backporting might be a new concept for those more familiar with proprietary software updates.
Here is an example of why we backport security fixes:
Red Hat shipped version 2.0.40 of the Apache HTTP Server with Red Hat Linux 8.0. Shortly after the release, a number of security issues were found and disclosed by the Apache Software Foundation. The Apache Software Foundation issued a new release, Apache HTTP Server 2.0.43, which contained fixes for those issues; however, in addition to the security fixes, a number of other changes (bug fixes and new features) were made between versions 2.0.40 and 2.0.43.
One of these features changed the module interface. In this case, if Red Hat issued a security update with version 2.0.43 of the Apache HTTP Server, replacing version 2.0.40, any modules customers were using would need to be updated (recompiled) to match the new module interface. If customers were using third-party modules, they would have had to go to their supplier of those modules to get updates. Moving from version 2.0.40 to 2.0.43 of the Apache HTTP Server would require manual effort by system administrators. Such an update would not be suitable for automated upgrade systems such as the Red Hat Network.
In cases like these, we can backport the updates. When we backport security fixes, we:
- identify the fixes and isolate them from any other changes,
- make sure the fixes do not introduce unwanted side effects, and
- apply the fixes to our previously released versions.
Explaining Common Release-Numbering Confusion
Backporting has a number of advantages for customers, but it can create confusion when it is not understood. Customers need to be aware that just looking at the version number of a package will not tell them if they are vulnerable or not. For example, stories in the press may include phrases such as "upgrade to Apache httpd 2.0.43 to fix the issue," which only takes into account the upstream version number. This can cause confusion as even after installing updated packages from a vendor, it is not likely customers will have the latest upstream version. They will instead have an older upstream version with backported patches applied.Also, some security scanning and auditing tools make decisions about vulnerabilities based solely on the version number of components they find. This results in false positives as the tools do not take into account backported security fixes.
Since the introduction of Red Hat Enterprise Linux, we have been careful to explain in our security advisories how we fixed an issue, whether by moving to a new upstream version or by backporting patches to the existing version. We have attached CVE names to all our advisories since January 2000, allowing customers to easily cross-reference vulnerabilities and find out how and when we fixed them, independent of version numbers.
We also supply OVAL definitions (machine-readable versions of our advisories) that third-party vulnerability tools can use to determine the status of vulnerabilities, even when security fixes have been backported. In doing this, we hope to remove some of the confusion surrounding backporting and make it easier for customers to always keep up to date with the latest security fixes.
http://gengwg.blogspot.com/
Comments
Post a Comment
https://gengwg.blogspot.com/