CVE-2013-0440: Medium severity oracle jre vulnerability
A flaw was discovered in the SSL/TLS in JSSE component of OpenJDK, that allows malicious clients to make an SSL/TLS server use an excessive amount of CPU time by repeatedly sending ClientHello packets. Client can send pre-generated packet, causing the server to repeatedly perform expensive computations when generating ServerHello response.
This flaw is similar to OpenSSL CVE-2011-4619 (bug #771780), but the problem does not seem to be caused by an attempt to support server gated cryptography (SGC) and rather seems to be caused by an incorrect enforcing of the packet order during the SSL/TLS protocol handshake.
Note that the attacker needs to keep connection open and keep re-sending ClientHello packets to keep server busy.
Other sources
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 through Update 11, 6 through Update 38, 5.0 through Update 38, and 1.4.240 and earlier, and OpenJDK 7, allows remote attackers to affect availability via vectors related to JSSE. NOTE: the previous information is from the February 2013 CPU. Oracle has not commented on claims from another vendor that this issue is related to CPU consumption in the SSL/TLS implementation via a large number of ClientHello packets that are not properly handled by (1) ClientHandshaker.java and (2) ServerHandshaker.java.
— MITRE
Affected Software
Event History
Frequently Asked Questions
What is the severity of CVE-2013-0440?
CVE-2013-0440 has been assigned a severity rating of medium due to its potential to consume excessive CPU resources.
How do I fix CVE-2013-0440?
To mitigate CVE-2013-0440, update your OpenJDK to the latest versions listed in the remediation guidelines.
What software is affected by CVE-2013-0440?
CVE-2013-0440 affects several versions of OpenJDK and Oracle JDK and JRE, including specific update levels.
Can CVE-2013-0440 be exploited remotely?
Yes, an attacker could exploit CVE-2013-0440 remotely by sending specially crafted ClientHello packets to the affected server.
Is there any workaround for CVE-2013-0440?
Currently, the best workaround for CVE-2013-0440 is to update the affected Java environments to the recommended secure versions.