On March 19 we wrote about how OpenSSL disclosed and fixed 13 vulnerabilities to address several security holes. Among the vulnerabilities addressed was CVE-2015-1787, which can result in a complete denial of service on an application compiled with OpenSSL library. This blog post will tackle how the bug can be exploited, and how Trend Micro can protect against future possible attacks.
CVE-2015-17187 also affects several protocols, including SSL/TLS and DTLS, which we will analyze in this entry.
Vulnerability description
The vulnerability is rooted in the method ssl3_get_client_key_exchange implemented in the file s3_srvr.c. This method processes the SSL/TLS Client Key Exchange Message. When ssl3_get_client_key_exchange is called, it will do a group of decisions and checks based on the length of the Client Key exchange message.
The length of the Client Key exchange message can be controlled by the attacker independent of the content of the message. A portion of ssl3_get_client_key_exchange in Figure 1.
The analysis was performed using the standard OpenSSL commands configuring it as a server and client. At the point of the function call at ssl3_get_client_key_exchange we have the following call graph:
Figure 1. ssl3_get_client_key_exchange call graph.
The following image shows the section where the Client Key exchange message length is calculated and stored in the variable n.
Figure 2. Client Key Exchange Message length in n
Note that if n==0 the method will continue the execution because this can be a valid case according to the TLS specification. This occurs when the client is sending a certificate containing a static DH exponent, and is mentioneded in section 7.4.7 of RFC5246, which we will tackle later on.
The next important critical section of the method is shown in the following image:
Figure 3. ssl3_get_client_key_exchange vulnerable code section
From the previous image we can see the vulnerable section of code inside of ssl3_get_client_key_exchange where the following preconditions are necessary:
- The algorithm alg_k needs be of type SSL_DHE. When this condition is valid, the variable skey will never be assigned to a valid key.
- If n == 0 then the DH parameters are taken from the client certificate. However, this is a valid action only if the algorithm is of type SSL_kDHr or SSL_kDHd.
- The final precondition is that value s-session-peer contains a valid certificate. This is the case when the client certificate authentication is present.
If these preconditions are valid, then the call to EVP_PKEY_cmp_parameters will crash the application because does not check if skey is null before accessing it.
This vulnerability rated with a “moderate” severity because it requires client authentication because the session must have a client certificate before the EVP_PKEY_cmp_parameters is called. The following section shows the real attack scenario.
Attack Delivery Mechanisms
As mentioned earlier, this CVE affects both SSL/TLS and DTLS. While the attack is very similar in both cases, in DTLS it is slightly different as DTLS implements message fragmentation at SSL Level. First, we will explain SSL/TLS and later DTLS.
SSL/TLS Attack Delivery
This vulnerability can be exploited if the attacker has access to a valid authentic certificate or can modify the traffic using a man-in-the-middle (MITM) attack. Only one byte needs to be altered: the client key exchange length. The following traffic capture shows a real attack traffic pattern:
Figure 4. Attack over TLS
In this scenario the attacker established a TLS version 1.2 session with the Client Key Exchange Length equal to 0. The algorithm used during the session was DHE-RSA-DES-CBC-SHA and from pcap we can see the client certificate sent to the server.
DTLS Attack Delivery
The method ssl3_get_client_key_exchange is also called from dtls1_accept. The following image shows the call graph of ssl3_get_client_key_exchange in DTLS.
Figure 5. DTLS ssl3_get_client_key_exchange.
The DTLS implementation uses the same ssl3_get_client_key_exchange but a successful attack requires changes to a different field in the protocol. If we change the client key exchange length (as we did for SSL/TLS), the attacks fails. This is because DTL implements a fragmentation mechanism at the SSL level where one SSL message can be split in several UDP packets (as specified in RFC4347). To be effective, the attack needs to reset to zero. The fragment length is shown as the following:
Figure 6. Attack over DTLS
Conclusion
CVE-2015-1787 has moderate impact and requires a valid client certificate. However, attacks can be implemented using MITM by changing only one byte, and the vulnerability affects both protocols SSL/TLS and DTLS. Patched versions of OpenSSL are now available.
To protect our customers, Deep Security for Web Apps scans and detects vulnerabilities and protects web applications via a single integrated solution. Additionally, we have published the following Deep Security rules, which we urge customers to apply as soon as possible:
- 1006621 – OpenSSL Client Authentication Handler ClientKeyExchange Message Denial Of Service Vulnerability (CVE-2015-1787)
