Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Overview

WhiteSource maintains a unique method for associating security vulnerabilities with their corresponding OS components. For each vulnerability in the database, the vulnerable source file is identified by a researcher and a link is automatically created between the vulnerable source file and the vulnerability ID.

However, with Linux vulnerabilities, associating vulnerabilities with their components is different. Linux distributions build their own packages, composed primarily of C projects. If the libraries or files of these projects are found to be vulnerable, the distribution or package may not be vulnerable, as multiple security patches are released by the Linux distributions. Conflicts have been found between detected vulnerabilities and the vulnerabilities published within each Linux distribution's official security advisory.

As a result, WhiteSource has changed its method for detecting vulnerabilities for Linux package associations. A new mechanism extracts the vulnerabilities from the relevant security advisory.

For example -https://access.redhat.com/security/security-updates/#/

NOTE: This mechanism is currently supported for RedHat Enterprise Linux (RPM-based), Debian, and Debian Ubuntu (DEB-based).

How Does the Mechanism Work?

Instead of linking the security vulnerabilities to the specific source files that were used to build the package, WhiteSource treats the package as a whole and associates them to it, based on the relevant security advisory.

This is applicable when scanning Docker images or using the Linux Package Manager mode (scanPackageManager).

Additional details, such as, information about the operating system and the relevant architecture, are detected and used to increase the accuracy of the results.

NOTE: This is applicable only when scanning Docker images or using the Linux Package Manager mode (scanPackageManager).

Use Case Examples

Debian 

The following example illustrates this method for a Debian distribution.

Detected Vulnerability: CVE-2018-20177

Vulnerable Package: “rdesktop_1.8.2-3_i386.deb”

In the CVE Advisory Page (https://security-tracker.debian.org/tracker/CVE-2018-20177 ), you can see the vulnerable package and relevant versions.

As shown above, this package “rdesktop” was fixed in version “1.8.4-1” and is vulnerable for the following Debian versions: Stretch, Buster, Bullseye, Bookworm.

This means that if a customer is using any of the above Debian versions through his operating system and is using the above package “rdesktop_1.8.2-3_i386.deb”, he is exposed to the vulnerability CVE-2018-20177.

On the other hand, if the customer is using Debian Wheezy through his operating system and is using the same package, he is not exposed to the vulnerability.

RedHat Enterprise 

The following example illustrates how vulnerabilities are detected for a RedHat Enterprise Linux distribution.

Detected Vulnerability: CVE-2021-2388

Vulnerable Package: “java-11-openjdk-11.0.9.11-2.el7_9.i686.rpm”

In the CVE Advisory Page (https://access.redhat.com/security/cve/CVE-2021-2388 ), you can see the vulnerable package and a link to the Fixed packages information: RHSA-2021:2784 - Security Advisory.


As shown above, this package “java-11-openjdk” was fixed in version “11.0.9.11-2” and is vulnerable for the RedHat Enterprise Linux versions:  RHEL 7 -- 7.9

This means that if a customer is using the above package “java-11-openjdk-11.0.9.11-2.el7_9.i686.rpm”, which is definitely related to RHEL 7.9 (it is reflected above the package name: “el7_9”), he is exposed to the vulnerability CVE-2021-2388.



  • No labels