The Effects of the TLS Session Renegotiation Vulnerability on Red Hat Directory Server 8.1

Updated -

Issue

A problem with session renegotiation was found in Secure Sockets Layer (SSL) version 3 and Transport Layer Security (TLS) version 1 protocols. An attacker could insert plain text as a prefix to communication between a client and server using a session renegotiation request. Red Hat Enterprise Linux has assigned this issue CVE-2009-3555, and numerous fixes are outlined in "Is Red Hat affected by TLS renegotiation MITM attacks (CVE-2009-3555)?"

During an SSL/TLS connection, either the server or the client can request that the session be renegotiated to do something like renew the session keys, select a different cipher suite for encryption, or authenticate to a resource using a certificate. An attacker could theoretically send a request to a server. Then, the attacker could trigger a renegotiation request in some way (such as trying to access a protected resource), and this text was prefixed to the legitimate request from the client. This is similar to a man-in-the-middle attack; Eric Rescorla's blog post "Understanding the TLS Renegotiation Attack" called it a blind prefix injection attack since the attacker inserted data without being able to decrypt the data sent between the server and client. The SSL/TLS protocol didn't provide a mechanism to verify that the session peers hadn't changed in the renegotiation process, so it was possible for a server to accept the request from the attacker because it didn't verify that the renegotiation request came from the client and only the client. (One thing to note: practical potential attacks using this flaw have only been identified for HTTPS.)

Red Hat Directory Server uses TLS/SSL for client connections (such as Admin Express, the Directory Server Console, tools such as ldapmodify,and servers like Red Hat Certificate System) as well as server-to-server connections for operations like replication, chaining, and Windows Sync.

For Red Hat Directory Server, support for SSL/TLS is implemented through the operating system's Network Security Services (NSS). To prevent the blind prefix injection attack, these system NSS packages have been updated.

Environment

The TLS vulnerability affects Directory Server 8.1 on Red Hat Enterprise Linux 4 and 5.

The SSL/TLS vulnerability is addressed in these versions of Red Hat Directory Server by updating the NSS packages with Errata RHSA-2010:0165.

Resolution on Red Hat Enterprise Linux

To resolve this issue, update the nss and nspr packages on the host machine for each Directory Server instance.

  1. Stop the Directory Server and Admin Server instances.
service dirsrv stop
service dirsrv-admin stop
  1. Update the system's nss packages.
yum update nss nspr

This installs NSS and NSPR, as well as any other system dependencies for the packages. If there are any dependencies, then you must approve their installation by selecting yes in the command line or GUI when prompted.

Check out the Knowledgebase article ["How do I apply package updates from the Red Hat Network?"](/knowledge/node/11258) for information on using `yum` to update a single package or the entire system.
  1. Restart the Directory Server and Admin Server.
service dirsrv start
service dirsrv-admin start
  1. Verify that the appropriate versions of NSS and NSPR have been installed. The versions must be the versions shown here or later.
rpm -qi nspr 
4.8.4

rpm -qi nss
3.12.6

Resolution on Sun Solaris

To resolve this issue, update the RHATdirsec-nssx and RHATdirsec-nsprx packages on the host machine for each Directory Server instance.

  1. Download the Solaris package from RHN.
  2. Stop the Directory Server and Admin Server instances.
/etc/init.d/dirsrv stop
/etc/init.d/dirsrv-admin stop
  1. Remove the original NSS and NSPR packages.
pkgrm -n RHATdirsec-nssx RHATdirsec-nsprx
  1. Install the new NSS and NSPR packages.
pkgadd -d /path/to/RHATdirsec-nsprx-4.8.4.sparcv9.pkg
pkgadd -d /path/to/RHATdirsec-nssx-3.12.6.sparcv9.pkg
  1. Restart the Directory Server and Admin Server.
/etc/init.d/dirsrv start
/etc/init.d/dirsrv-admin start

Comments