1. Overview:

The java-1.7.0-openjdk packages provide the OpenJDK 7 Java Runtime Environment and the OpenJDK 7 Java Software Development Kit.

Multiple flaws were discovered in the 2D, CORBA, JMX, Libraries and RMI components in OpenJDK. An untrusted Java application or applet could use these flaws to bypass certain Java sandbox restrictions. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2015-4760, CVE-2015-2628, CVE-2015-4731, CVE-2015-2590, CVE-2015-4732 and CVE-2015-4733 to these issues.

A flaw was found in the way the Libraries component of OpenJDK verified Online Certificate Status Protocol (OCSP) responses. An OCSP response with no nextUpdate date specified was incorrectly handled as having unlimited validity, possibly causing a revoked X.509 certificate to be interpreted as valid. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2015-4748 to this issue.

It was discovered that the JCE component in OpenJDK failed to use constant time comparisons in multiple cases. An attacker could possibly use these flaws to disclose sensitive information by measuring the time used to perform operations using these non-constant time comparisons. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2015-2601 to this issue.

A flaw was found in the RC4 encryption algorithm. When using certain keys for RC4 encryption, an attacker could obtain portions of the plain text from the cipher text without the knowledge of the encryption key. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2015-2808 to this issue.

Note: With this update, OpenJDK now disables RC4 SSL/TLS cipher suites by default to address the CVE-2015-2808 issue. Refer to Red Hat Bugzilla bug CVE-2015-2628
1207101, linked to in the References section, for additional details about this change.

A flaw was found in the way the TLS protocol composed the Diffie-Hellman (DH) key exchange. A man-in-the-middle attacker could use this flaw to force the use of weak 512 bit export-grade keys during the key exchange, allowing them do decrypt all traffic. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2015-4000 to this issue.

Note: This update forces the TLS/SSL client implementation in OpenJDK to reject DH key sizes below 768 bits, which prevents sessions to be downgraded to export-grade keys. Refer to Red Hat Bugzilla bug 1223211, linked to in the References section, for additional details about this change.

It was discovered that the JNDI component in OpenJDK did not handle DNS resolutions correctly. An attacker able to trigger such DNS errors could cause a Java application using JNDI to consume memory and CPU time, and possibly block further DNS resolution. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2015-4749 to this issue.

Multiple information leak flaws were found in the JMX and 2D components in OpenJDK. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the names CVE-2015-2621 and CVE-2015-2632 to these issues.

A flaw was found in the way the JSSE component in OpenJDK performed X.509 certificate identity verification when establishing a TLS/SSL connection to a host identified by an IP address. In certain cases, the certificate was accepted as valid if it was issued for a host name to which the IP address resolves rather than for the IP address. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2015-2625 to this issue.

More information about these vulnerabilities can be found in the security advisory issued by Red Hat:

• https://rhn.redhat.com/errata/RHSA-2015-1230.html

2. Avaya System Products using a modified version of RHEL5 with affected packages installed:

Recommended Actions for System Products:
Avaya strongly recommends following networking and security best practices by implementing firewalls, ACLs, physical security or other appropriate access restrictions. Though Avaya believes such restrictions should always be in place, risk to Avaya products and the surrounding network from this potential vulnerability may be mitigated by ensuring these practices are implemented until such time as an Avaya provided product update or the recommended Avaya action is applied. Further restrictions as deemed necessary based on the customer's security policies may be required during this interim period, but the System Product operating system or application should not be modified unless the change is approved by Avaya. Making changes that are not approved may void the Avaya product service contract.

Mitigating Factors:

When determining risk, Avaya takes into account many factors as outlined by Avaya's Security Vulnerability Classification Policy. The following table describes factors that mitigate the risk of specific vulnerabilities for affected Avaya products:

3. Avaya Software-Only Products:

Avaya software-only products operate on general-purpose operating systems. Occasionally vulnerabilities may be discovered in the underlying operating system or applications that come with the operating system. These vulnerabilities often do not impact the software-only product directly but may threaten the integrity of the underlying platform.

In the case of this advisory Avaya software-only products are not affected by the vulnerability directly but the underlying Linux platform may be. Customers should determine on which Linux operating system the product was installed and then follow that vendor's guidance.

Recommended Actions for Software-Only Products:
In the event that the affected package is installed, Avaya recommends following recommended actions supplied by Red Hat regarding their Enterprise Linux.

4. Additional Information:

Additional information may also be available via the Avaya support website and through your Avaya account representative. Please contact your Avaya product support representative, or dial 1-800-242-2121, with any questions.

5. Disclaimer:

ALL INFORMATION IS BELIEVED TO BE CORRECT AT THE TIME OF PUBLICATION, IS PROVIDED "AS IS", AND IS APPLICABLE ONLY TO PRODUCT VERSIONS ELIGIBLE FOR MANUFACTURER SUPPORT IN ACCORDANCE WITH AVAYA PRODUCT LIFE CYCLE POLICY. AVAYA INC., ON BEHALF ITSELF AND ITS SUBSIDIARIES AND AFFILIATES (HEREINAFTER COLLECTIVELY REFERRED TO AS "AVAYA"), DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE AND FURTHERMORE, AVAYA MAKES NO REPRESENTATIONS OR WARRANTIES THAT THE STEPS RECOMMENDED WILL ELIMINATE SECURITY OR VIRUS THREATS TO CUSTOMERS' SYSTEMS. IN NO EVENT SHALL AVAYA BE LIABLE FOR ANY DAMAGES WHATSOEVER ARISING OUT OF OR IN CONNECTION WITH THE INFORMATION OR RECOMMENDED ACTIONS PROVIDED HEREIN, INCLUDING DIRECT, INDIRECT, INCIDENTAL, STATUTORY, CONSEQUENTIAL DAMAGES, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF AVAYA HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

THE INFORMATION PROVIDED HERE DOES NOT AFFECT THE SUPPORT AGREEMENTS IN PLACE FOR AVAYA PRODUCTS. SUPPORT FOR AVAYA PRODUCTS CONTINUES TO BE EXECUTED AS PER EXISTING AGREEMENTS WITH AVAYA.

6. Revision History:

V 1.0 - July 21, 2015 - Initial Statement issued.
V 2.0 - October 25, 2016 - Updated affected versions and actions for SP and set advisory status to final.

Avaya customers or Business Partners should report any security issues found with Avaya products via the standard support process.
Independent security researchers can contact Avaya at [email protected].

Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

© 2015 Avaya Inc. All Rights Reserved. All trademarks identifying Avaya products by the ® or ™ are registered trademarks or trademarks, respectively, of Avaya Inc. All other trademarks are the property of their respective owners.