HP Security Products Blog
From applications to infrastructure, enterprises and governments alike face a constant barrage of digital attacks designed to steal data, cripple networks, damage brands, and perform a host of other malicious intents. HP Enterprise Security Products offers products and services that help organizations meet the security demands of a rapidly changing and more dangerous world. HP ESP enables businesses and institutions to take a proactive approach to security that integrates information correlation, deep application analysis and network-level defense mechanisms—unifying the components of a complete security program and reducing risk across your enterprise. In this blog, we will announce the latest offerings from HP ESP, discuss current trends in vulnerability research and technology, reveal new HP ESP security initiatives and promote our upcoming appearances and speaking engagements.

SSLv3/TLS Renegotiation Stream Injection

Recently, Thursday 11/5/09, a few folks over on the IETF mailing list went public with a limited Man-in-the-Middle attack on SSLv3 and TLS. There has been quite a bit of press coverage on this issue's severity. However, the way this attack can be used is proving to be more dangerous in specific contexts than at first thought. This vulnerability affects almost every SSL/TLS implementation: IIS (5|6|7), Apache mod_ssl < 2.2.14, OpenSSL < 0.9.8l, GnuTLS < 2.8.5, Mozilla NSS < 3.12.4, and certainly more. Any products using these libraries as their underlying secure transport layer are also vulnerable to this content injection vulnerability. This vulnerability has been assigned CVE-2009-3555 by Mitre and I'm sure they will continue to update their listing with newly affected packages as they are found.

At a high level, this is not a true Man-in-the-Middle attack. An attacker leveraging this vulnerability can only inject data and is unable to read client traffic or server responses. While this is not an entire compromise, there are novel attacks that can be performed in the context of HTTP and SSLv3/TLS. In order for SSLv3/TLS to support long running sessions, at a protocol level, encryption keys must be changed to ensure cryptographic security. However, the real problem manifests within the communication between an application and the SSLv3/TLS library the server is using. Since HTTP requests cannot be processed until they are complete, web servers keep the request in a buffer until it is complete. When the SSLv3/TLS libraries receive new packets they are immediately forwarded to the web server once decrypted at a protocol level. The issue here lies within that caching behavior; before completing the HTTP request, the client initiates a key renegotiation then sending new keys. Except these new keys could have been from the client connecting to the man-in-the-middle and just simply forwarded by the attacker. This is especially malicious because the client will never know he has been man-in-the-middled as the communication between her and the server appears completely normal. Unfortunately, prior to this vulnerability disclosure SSLv3/TLS enabled web servers do NOT flush the data buffers before the renegotiation. Thus an attacker can leverage this optimization/feature/whatever to inject data into the beginning of the conversation between the unexpecting client and the web server.

Given an attacker can get traffic routed through him (this is easy in a WiFi environment or with arp poisoning) the attacker can effectively transparently proxy a client's request through him. Now using this vulnerability, any HTTPS connection through him can have arbitrary data from the attacker prepended to anything the client sends. This is especially bad for HTTP requests.

These theoretical attacks all require some type of renegotiation to occur. Luckily, for an attacker, there are simple ways that can be utilized. The possible ways renegotation can be forced are:

  • Any server that allows client renegotiation.

  • Servers with public access to a subset of folders, and a set of secure folders requiring a client certificate.

  • Servers that renegotiate for any reason.

Of course the libraries have quickly identified and fixed some of the issues that cause this vulnerability. OpenSSL has disabled renegotiation for SSLv3 and TLS in a patch. GnuTLS has implemented some of the drafted larger fixes for TLS specifically. Apache has fixed the some of the issues at the application layer associated with the prepended attacks, but this still requires patches of openssl to completely solve all the certificate attacks (doesn't prevent from server initiated renegotiation).

WebInspect will now also test any SSL web servers for this vulnerability with Check ID 10942. Simply SmartUpdate to receive the latest checks.

Labels: MitM| Research| SSLv3| TLS
Showing results for 
Search instead for 
Do you mean 
About the Author(s)
Top Kudoed Posts
HP Blog

HP Software Solutions Blog


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.