Your submission was sent successfully! Close

You have successfully unsubscribed! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates about Ubuntu and upcoming events where you can meet our team.Close

CVE-2009-3555

Publication date 9 November 2009

Last updated 24 July 2024


Ubuntu priority

The TLS protocol, and the SSL protocol 3.0 and possibly earlier, as used in Microsoft Internet Information Services (IIS) 7.0, mod_ssl in the Apache HTTP Server 2.2.14 and earlier, OpenSSL before 0.9.8l, GnuTLS 2.8.5 and earlier, Mozilla Network Security Services (NSS) 3.12.4 and earlier, multiple Cisco products, and other products, does not properly associate renegotiation handshakes with an existing connection, which allows man-in-the-middle attackers to insert data into HTTPS sessions, and possibly other types of sessions protected by TLS or SSL, by sending an unauthenticated request that is processed retroactively by a server in a post-renegotiation context, related to a "plaintext injection" attack, aka the "Project Mogul" issue.

Read the notes from the security team

Status

Package Ubuntu Release Status
apache2 10.04 LTS lucid
Fixed 2.2.14-2ubuntu1
9.10 karmic
Fixed 2.2.12-1ubuntu2.1
9.04 jaunty
Fixed 2.2.11-2ubuntu2.5
8.10 intrepid
Fixed 2.2.9-7ubuntu3.5
8.04 LTS hardy
Fixed 2.2.8-1ubuntu0.14
6.06 LTS dapper
Fixed 2.0.55-4ubuntu2.9
gnutls12 10.04 LTS lucid Not in release
9.10 karmic Not in release
9.04 jaunty Not in release
8.10 intrepid Not in release
8.04 LTS hardy Not in release
6.06 LTS dapper Ignored
gnutls13 10.04 LTS lucid Not in release
9.10 karmic Not in release
9.04 jaunty Not in release
8.10 intrepid Not in release
8.04 LTS hardy Ignored
6.06 LTS dapper Not in release
gnutls26 10.04 LTS lucid Ignored
9.10 karmic Ignored
9.04 jaunty Ignored
8.10 intrepid Ignored
8.04 LTS hardy Not in release
6.06 LTS dapper Not in release
libapache-mod-ssl 10.04 LTS lucid Not in release
9.10 karmic Not in release
9.04 jaunty Not in release
8.10 intrepid Not in release
8.04 LTS hardy Not in release
6.06 LTS dapper Ignored
nss 10.04 LTS lucid
Fixed 3.12.6-0ubuntu2
9.10 karmic
Fixed 3.12.6-0ubuntu0.9.10.1
9.04 jaunty
Fixed 3.12.6-0ubuntu0.9.04.1
8.10 intrepid Ignored
8.04 LTS hardy
Fixed 3.12.6-0ubuntu0.8.04.1
6.06 LTS dapper Not in release
openjdk-6 10.04 LTS lucid
Not affected
9.10 karmic
Fixed 6b16-1.6.1-3ubuntu3
9.04 jaunty
Fixed 6b14-1.4.1-0ubuntu13
8.10 intrepid
Fixed 6b12-0ubuntu6.7
8.04 LTS hardy
Fixed 6b11-2ubuntu2.2
6.06 LTS dapper Not in release
openjdk-6b18 10.10 maverick
Fixed 6b18-1.8.2-4ubuntu1
10.04 LTS lucid
Not affected
9.10 karmic
Not affected
8.10 intrepid Not in release
8.04 LTS hardy Not in release
6.06 LTS dapper Not in release
openssl 10.04 LTS lucid
Fixed 0.9.8k-7ubuntu8.1
9.10 karmic
Fixed 0.9.8g-16ubuntu3.2
9.04 jaunty
Fixed 0.9.8g-15ubuntu3.5
8.10 intrepid Ignored
8.04 LTS hardy
Fixed 0.9.8g-4ubuntu3.10
6.06 LTS dapper
Fixed 0.9.8a-7ubuntu0.12
sun-java6 10.10 maverick
Fixed 6.22-0ubuntu1~10.10
10.04 LTS lucid
Fixed 6.22-0ubuntu1~10.04
9.10 karmic
Fixed 6.22-0ubuntu1~9.10.1
9.04 jaunty
Fixed 6.22-0ubuntu1~9.04.1
8.04 LTS hardy
Fixed 6.22-0ubuntu1~9.04.1
6.06 LTS dapper Not in release

Notes


jdstrand

Fixing this issue requires coordination between the IETF, SSL libraries (eg OpenSSL and GnuTLS) and TLS consumers (notably HTTPS servers, but most (or all) servers using TLS which support TLS renegotiation). Protocol-breaking changes are among the possibilities being discussed. The following is based on http://extendedsubset.com/Renegotiating_TLS.pdf and http://extendedsubset.com/Renegotiating_TLS_pd.pdf. You are encouraged to read this document as well as the email thread on ietf-tls for complete information and most up-to-date status (see References). There are essentially 3 types of renegotiation scenarios known at this time to be vulnerable, and they all require a man-in-the-middle (MITM) attack: 1. Client certificate authentication: servers configured to require client certificate authentication on a per-directory basis. Apache is known to be vulnerable when using this configuration. There is no generally usable mitigation strategy known at this time. 2. Differing server cryptographic requirements: servers configured to support different cipher suites within the same site. One mitigation strategy is to require all content on a site to use a single cipher suite. Disallowing specification of TLS parameters in .htaccess files (generally modifiable by end users) may also be a good idea. 3. Client-initiated renegotiation: servers configured for TLS. Apache is known to be vulnerable when using using TLS and the client initiates a renegotiation. There is no generally usable mitigation strategy known at this time. The flaw should not allow the attacker to see the contents of the connection, and a client cannot be redirected to another site. For the HTTPS scenarios listed above, the attacker is able to perform arbitrary requests with the credentials of the victim. Arbitrary POST requests may also be possible. Analysis on the effects of this flaw for other protocols is ongoing. Until a general fix can be found for Ubuntu, users may be interested in reading http://www.links.org/?p=780, which has a patch to OpenSSL to disable all renegotiation. Update for apache2 disabled client initiated renegotiations. This won't fix per-Directory/Location configurations.


mdeslaur

openssl 0.9.8l disabled renegotiations completely, with a compile time option to turn it back on. This may break connections to servers that haven't been patched. openssl 0.9.8m adds an option that applications can use to turn it back on: http://groups.google.com/group/mailing.openssl.cvs/browse_thread/thread/8d8add96fa471695 Turning renegotiation off completely may break postgresql, openvpn alpine, psi, fetchmail, etc. http://www.mail-archive.com/[email protected]/msg26800.html


jdstrand

NSS 3.12.6 has support for the new renegotiation extension for TLS to implement rfc5746. NSS clients advertise their support for this extension and if the server also supports it, will be protected from this vulnerability. To maintain compatibility, NSS in Ubuntu will for the foreseeable future use the so-called 'transitional' mode which will fall back to the unprotected renegotiation method if the server doesn't support the new extension. NSS was fixed in Ubuntu 9.10 because the new Firefox required it. Because Firefox needs changes to take advantage of the new NSS, once Ubuntu 8.04 LTS - 9.04 are updated to use an embedded NSS (and therefore won't use the system NSS), we can update the system NSS for these releases. When upgrading the system NSS on Ubuntu 8.04 LTS - 9.04, be careful about https://launchpad.net/bugs/559881 and https://launchpad.net/bugs/559918 (regressions seen with the 9.10 update). postgresql 8.1.20, 8.3.10 and 8.4.3 now have ssl_renegotiation_limit to control session key renegotiation preliminary GNUtls patches at (in 2.9.10 development release): http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/3944 http://git.savannah.gnu.org/gitweb/?p=gnutls.git&a=search&h=HEAD&st=commit&s=renegotiation


mdeslaur

jetty 6.1.22 has a CVE-2009-3555 fix: "Prevent SSL renegotiate for SSL vulnerability"


jdstrand

RedHat RHSA-2010:0396-01 adds the "SSLInsecureRenegotiation" configuration directive to apache


mdeslaur

gnutls doesn't have an API for renegotiations, so ignoring.

Patch details

For informational purposes only. We recommend not to cherry-pick updates. How can I get the fixes?

Package Patch details
apache2
gnutls12