Description |
Need to review software packages on linux hosts for backported security fixes when the base version of that software is flagged for security issues. |
Scope |
Affected hosts running linux. |
Solution |
What is backporting?Backporting describes the action of taking a fix for a security flaw out of the most recent version of an upstream software package and applying that fix to an older version of the package that is distributed.
Backporting is a common practice among vendors like Canonical, Red Hat, SUSE and others and is essential to ensuring these vendors can deploy automated updates to customers with minimal risk.
How does backporting affect me?When Lacework performs a vulnerability assessment for either your hosts or container images, it compares the installed package version to a list of known vulnerabilities for the installed version and ranks the severity in accordance to published CVE (Common Vulnerabilities and Exposures) notices.
When a package has been backported with a fix from a later software version, it is possible that you may see vulnerability alerts for such packages. In such cases, the alert you received could be a 'false positive', because the package version matches for known vulnerabilities but has actually already been patched with a fix to resolve that vulnerability.
How do I know if an installed package has been backported with a fix?Unfortunately, it is not always easy to determine whether or not an installed package contains a backported fix to a known vulnerability and when unable to make this determination, it is always safest to assume the package may be vulnerable.
However, software maintainers typically distribute a change log containing a manifest of patches and changes along with the reason behind a particular change. To the extent that information is available about backported fixes for specific vulnerabilities in a software package, the change log is the most likely place to find it.
Note: Not all package maintainers keep a change log or notate security backports, in which case you should assume the package may be vulnerable and treat the vulnerability notice as legitimate.
How to locate and review these change-logs will largely depend on your OS distribution and version and how the package was installed. Please follow the steps outlined below that correspond to your OS distribution.
ResolutionUbuntu/DebianFor packages installed with aptitude via apt-get or apt, you can use the following command syntax to output the change-log of an installed package and search for the corresponding CVE number, replacing <PackageName> and <CVE-#> with your own values:
Option 1: apt-get
Example output:
Option 2: zcat If the apt cache doesn't contain the changelog information, the changelogs can also be directly viewed at /usr/share/doc/<PackageName>/changelog.Debian.gz:
Example Output:
RHEL/Fedora/CentOS/AmazonLinuxFor packages installed via yum or dnf, you can use the following command syntax to output the change-log of an installed package from rpm and search for the corresponding CVE number, replacing <PackageName> and <CVE-#> with your own values:
Example output:
SUSE/SLESFor SUSE or SLES, the steps outlined above for RedHat based distros work, since zypper uses rpm underneath to install packages. In addition to being able to query rpm for the changelog, SUSE provides an additional option of getting more information on backported patches specific to CVEs
Example output:
This output will confirm the patch that contains a fix to the vulnerability described in the CVE notice and let you know whether or not this patch is needed or not. If the status column shows as "not needed" the patch has already been applied. If the command returns no output at all, the package should be treated as not backported with a fix. |