Recently we noticed a security patch has been published for the OpenSSL vulnerability called SSL Death Alert. As with other serious security vulnerabilities, this one grabbed our attention because the discover er of the vulnerability says that it may cause a denial of service to an OpenSSL web server. To better protect our customers from this attack and provide detection and prevention for this vulnerability, the McAfee Labs IPS Vulnerability Research team looked into this issue.
Our analysis started with the patch differences report of the newly pushed code.
As we can see in the diffing results, a couple of files have been modified to fix this problem.
The patch diff of include/openssl/ssl.h reveals the new error code SSL_R_TOO_MANY_WARN_ALERTS (409) has been introduced.
In ssl/record/record_locl.h, we can see the directive MAX_WARN_ALERT_COUNT has been introduced and is set to 5.
Now let’s look into the actual patch, which sits in the files ssl/record/rec_layer_d1.c and ssl/record/rec_layer_s3.c.
The following screen shots show the patch changes in the two files.
ssl/record/rec_layer_d1.c
ssl/record/rec_layer_s3.c
As we can see, the patch is pretty simple and straightforward. It simply counts the layers of consecutive SSL3_AL_WARNING alert packets and checks if the count exceeds five. If the count is greater than five, it raises an error.
Exploiting this issue
To provide detection and prevention for this DoS attack, we created a minimal proof of concept. Although there is no public exploit, the advisory provides a lot of technical details. To exploit this bug, we must initiate the SSL handshake. As a part of the handshake the attacker has to send a genuine Client Hello packet to the server. The following screen shot shows a packet capture of the first stage of the exploit, a normal Client Hello packet.
As described in the security advisory, to exhaust the CPU, we need to send a large number of crafted cleartext SSL3_AL_WARNING alert packets to the server. To do this, we must understand the structure of an alert packet. The message looks like the following, from this TLS protocol memo.
An alert message can be encrypted, but in this case we have to send a cleartext alert to the vulnerable server.
The following screen shot shows captured SSL3_AL_WARNING packets in our test environment.
Next we see multiple alerts packed inside a single record.
The alert packet structure looks like this:
To test the developed exploit, we configured a test server with OpenSSL and self-signed certificate and private key. The following screen shot shows the server listening to port 4433 and communicating with an SSL client.
During normal SSL communications between server and client, we see nothing abnormal with CPU consumption of server processes.
As soon as we run the exploit against the server, however, we immediately see the server process stops responding as CPU usage reaches 99% and then 100% after a few seconds.
The CPU spike causes a denial of service by the OpenSSL Server as it becomes inaccessible. In our test environment, we noticed the SSL service resumes as soon as we stop the exploit from sending malicious packets.
Server administrators should apply the patch to OpenSSL servers as soon as possible. McAfee Network Security Platform (IPS) signature 0x45c09000 provides detection and prevention for this attack.
Stay Updated
Follow us to stay updated on all things McAfee and on top of the latest consumer and mobile security threats.
