Exadata X4-2 Hardware
 
Oracle SuperCluster M7 Hardware
 
Exadata X5-2 Hardware
 
Oracle SuperCluster T5-8 Hardware
 
SPARC SuperCluster T4-4
 
Oracle SuperCluster M6-32 Hardware
 

PLA-Support>Eng Systems>Exadata/ODA/SSC>Oracle Exadata>DB: Exadata_EST
 

The goal of this document is to assist in determining if one or more identified CVEs apply to an Oracle Exadata or SuperCluster system.

Applies to:

Goal

The goal of this document is to assist in determining if one or more identified CVEs apply to an Oracle Exadata or SuperCluster system.

For vulnerabilities affecting Oracle Database Appliances (ODA), see Doc ID 2195990.1.

For vulnerabilities affecting the Cisco 4948 switches in Engineered Systems, see Doc ID 2232764.1.

For vulnerabilities that do not have a CVE AND require a cipher to be disabled, see Doc ID 2198093.1.

For vulnerabilities that do not have a CVE AND required changing the default SNMP community string, see Doc ID 2181438.1.

For CVEs specific to a particular application such as Enterprise Manager, also review Doc ID 1074055.1.

Solution

Background:

Security scans show results for two types of vulnerabilities:

• Vulnerabilities with an assigned CVE.  CVE stands for Common Vulnerabilities and Exposures. The CVE system provides a reference-method for specific publicly known information-security vulnerabilities and exposures. The National Cybersecurity federally funded research and development center, owned by The MITRE Corporation, maintains the system, with funding from the National Cyber Security Division of the United States Department of Homeland Security.  When a CVE is published, all of the software affected by it will be patched to fix the vulnerability. This will result in one or more new updated packages for the affected software. In the case of Oracle Linux, patches are released via an Enterprise Linux Security Advisory (aka ELSA). In the case of the Solaris OS, patches are released via an Oracle Solaris Third Party Bulletin.

• Vulnerabilities without an assigned CVE.  These vulnerabilities do not have a specific cause and are generally more of a best practice nature.  They address broader security related topics that have been found to be important to hardening security of a computing environment.  Generally, there will be no patches/updates to apply to resolve this type but configuration changes may be recommended.

ORACLE SUPPORT ENGINEERS

This document is intended to be followed by the customer to locate and apply fixes for known vulnerabilities.  If a customer has not followed this document, have them do so or assist them with the process listed herein.

DO NOT TRANSFER the SR to the Security Certified Group (SCG) if a fix is already available for the vulnerability.  Only transfer the SR to the SCG if it meets one or more of the following criteria:

• the steps in this document have been followed and no fix has been found
• contains a request by the customer for a vulnerability fix that is outside of the normal bug/release process
• contains questions about when a vulnerability fix will be released
• the customer believes they may have found a security NEW vulnerability

Steps to Address an Identified Vulnerability:

Exadata Including Storage Cells On SuperCluster (Linux OS):

1. Does the vulnerability listed in the report have a CVE associated with it (for example: CVE-2017-1138)?

    If yes, go to step 5.

    If no, go to step 2.

2. Does the vulnerability listed in the report have a ELSA associated with it (for example, ELSA-2017-1701)?

    If yes, go to step 3.

    If no, skip to step 14.

3. Go to https://linux.oracle.com/pls/apex/f?p=105:21 , enter the ELSA in the search field and click the Go button.  The ELSA will appear in the search results.

4.  Click the link to the ELSA in the search results then skip to step 11.

5.  Open Doc ID 1405320.1.

6. Search the doc for the CVE number.

    If the CVE appears in the doc review the "Comment Column" for information and instructions on resolving the CVE finding. Also review the "Fixed In" column to determine the Exadata image that the issue was fixed in. If you are on a version below the one listed in this column, it is   recommended that you update to this image version.  For example, CVE-2008-5161 did not affect Oracle Linux 5 but did affect Oracle Linux 6. The vulnerability was fixed in Exadata image version 11.2.3.3.0. All subsequent images contain the fix. Therefore if your Exadata is on image version 11.2.3.3.0 or higher, this vulnerability does not apply. If your Exadata is on a version below 11.2.3.3.0, then you will need to update to the latest image available for your system.  Fix the issue then skip to step 15.

    If the CVE does not appear in the doc, go to the next step.
 

7. Go to the following link to determine the Oracle Enterprise Linux Security Advisory (ELSA) that corresponds to the CVE.

          http://linux.oracle.com/pls/apex/f?p=130:21

    Enter the CVE in the "Search" field then click on the "Go" button.

    If the CVE has an associated ELSA, the CVE will appear in the search results with details of the problem as seen in this example.  Go on to the next step.

    If the CVE does not have an associated ELSA then no results for this CVE search will appear.  Skip to step 15.

8. Click on the CVE number. Details about the CVE will appear.

9. In the CVE details, locate the column labeled “Platform”. This lists the Oracle Linux version that the CVE applies to.

    If your version of Linux is listed in the “Platform” column, then this vulnerability applies and an ELSA will be listed in the "Errata" column. Go to the next step.   If the "Superseded By Advisory" has an ELSA listed, refer to that ELSA instead as it is the most current then go to the next step.

    If your version of Linux is not listed in the “Platform” column, there will be no ELSA. This is because the issue covered by the CVE does not affect your version of Linux.  Skip to step 15.

10.  Determine what Linux packages are affected by clicking on the Errata number listed in the “Errata” column.  This will take you to the ELSA information that lists the Linux packages affected by this vulnerability.

In some cases a vulnerability may affect the customer's version of Linux but a patch was not produced. This can be for a number of reasons. One of the major reasons is that Oracle Linux is based on Red Hat Enterprise Linux (RHEL) and therefore many of the patches we release are based on patches produced by Red Hat. In some cases, Red Hat will not produce a patch because the version of RHEL has reached End-Of-Life and is no longer supported.  In other cases, they will not release a patch because the particular build of that package was not affected.

If a patch is not available and the customer would like further follow-up, transfer the SR to the SCG.

11.  All packages that require updating will be listed, grouped by the version of Oracle Linux and the architecture (i.e. - Oracle Linux 5 (i386), Oracle Linux 6 (x86_64), etc).  Locate the list of packages that matches your version of Oracle Linux and the architecture. 

12.  Query the change log for the affected packages to see if the CVE has already been addressed in it. For example, the following command will query the Firefox package to check for the fix for CVE-2017-5428.

     If a result is not returned, then the CVE has not been addressed.  Go to the next step.

     If a result is returned, then the CVE is addressed and is not applicable.  Skip to step 15.

13.  Determine whether or not the affected package has an available update and if that package can be updated.

      DO NOT UPGRADE THE KERNEL ON AN EXADATA SYSTEM USING YUM OR RPM UNLESS TOLD TO DO SO BY ORACLE SUPPORT.

     If the packages affected are kernel packages, you must wait until an Exadata image with the kernel version specified in the Errata (or higher) is available.  Skip to step 15.

     If the packages affected are glibc packages, see Doc ID 1965525.1 for information on how to update glibc.  However, it is highly recommended to wait until an Exadata image with a fixed version of glibc is released.

     If the packages affected are Java packages, see Doc ID 2069987.1 (compute nodes) and Doc ID 2075464.1 (cell nodes) for instructions.

     If the packages affected are related to Xen, it is recommended to only update these using Exadata images to avoid problems with deployed VMs.

     If the packages affected are gnutls packages and:

          - your Exadata image is version 12.1.2.2.0 or higher, then the gnutls packages can be removed.  These packages were removed in version 12.1.2.2.0 and are no longer required.  Skip to step 15.

          - your Exadata image image version is below 12.1.2.2.0, you can update the installed gnutls package(s) via the YUM utility (e.g. - # yum update <packageName>) then skip to step 15.   Reference: SR 3-14627268878

     If the packages affected are ibutils packages, you must wait until an Exadata image with the updated ibutils package is available.  Skip to step 15.

     For all other packages, update just the package individually using one of the following two methods:

          - If your Exadata is able to access the internet, you may use the YUM utility as root to update a single package.   For example: yum update <packageName> . 

          - If your Exadata is not able to access the internet, you must download the required updated package from the Oracle Public Yum Repository and install it as root using the rpm command.   For example: rpm -Uvh <packageName> .   Refer to Doc ID 2312778.1 for more information.

     Once you have determined what action to take regarding package updates based on the above information (and update packages is applicable), skip to step 15.

14. If you are at this step then no Oracle documentation regarding this vulnerability is immediately available to you.  Please make note of this vulnerability (including the CVE if one is associated) and the components affected (cell nodes, IB switches, etc) the go to the next step.

15. Repeat steps the above steps for each vulnerability.   Once all vulnerabilities in the report have been addressed, go to the next step.

16. If any vulnerabilities were noted in step 8, open a Service Request (SR) with Oracle Support and include the list of vulnerabilities that need further research.  Please reference any CVE associated with the vulnerabilities.

     Additionally, you can open an SR if you need further clarification on the applicability of a specific vulnerability recommendation.

Oracle Support Engineers

Perform the above steps to confirm the customer did not miss anything. If no fix is found, transfer the SR to the SCG using option 5 and noting that this doc was followed.

SuperCluster (Solaris OS):

1. Does the vulnerability listed in the vulnerability report have a CVE associated with it?

     If yes, go to the next step.

     If no, go to step 10.

2. Go to Doc ID 1448883.1.

3. Search for the CVE in the doc.

    If the CVE is listed in the doc, go to the next step.

    If the CVE is not listed in the doc, go to step 6.

4. In the “Resolution” column will be the version of Solaris that the vulnerability was fixed in.

    If your version of Solaris is below the version listed, then go to the next step.

    If your version of Solaris is at or above the version listed, then go to step .

5. Click on the version link in the document. This will take you to a document containing instructions on how to apply the update. Apply the update to fix the vulnerability then go to step 11.

6. Go to Doc ID 2052590.1.

7. Search for the CVE in the doc.

    If the CVE is listed, download and install the applicable IDR listed in the “Resolution” column then go to step 11.

    If the CVE is not listed in the doc, go to step 8.

8.  Go to Doc ID 2086278.1.

9.  Search for the CVE in the doc.

     If the CVE is listed, read the information for the CVE that applies to your version of Solaris then apply any recommended IDRs.

     If you cannot find the CVE in the doc, then the CVE is either not applicable to Solaris or has not been addressed yet. Go to the next step.

10.  If you are at this step then no Oracle documentation regarding this vulnerability is immediately available to you. Please make note of this vulnerability (including CVE if one is associated) and the components affected (cell nodes, IB switches, etc).

11. Repeat the above steps for each vulnerability.

12. If any vulnerabilities were noted in step 10, open a Service Request (SR) with Oracle Support and include the list of vulnerabilities that need further research.  Please reference only CVEs associated with any vulnerabilities.

     Additionally, you can open an SR if you need further clarification on the applicability of a specific vulnerability recommendation.

Oracle Support Engineers

Perform the above steps to confirm the customer did not miss anything. If no fix is found, transfer the SR to the SCG using option 5 and noting that this doc was followed.

References

This solution has no attachment