VanDyke Software

Security Advisory

CERT Vulnerability Note - Timing Attack Vulnerabilities

"Cryptographic libraries and applications do not adequately defend against timing attacks"

On March 25, 2003, CERT published a vulnerability note regarding remote timing attacks against RSA private keys. Any applications that perform RSA private key operations may be vulnerable and could allow a remote timing attack. As explained in the CERT/CC Vulnerability Note: VU#997481, SecureCRT® 4.0.4 and earlier may be vulnerable when SSH1 is used. SSH2 connections are not affected by the vulnerability. No other VanDyke Software product is affected by this vulnerability. SecureCRT 4.0.9 and newer provides a fix for SSH1 connections.


Posted: March 25, 2003
Updated: April 3, 2003

Overview

Brumley & Boneh, initially reported this vulnerability to CERT. Brumley & Boneh, researchers at Stanford University, have written a paper that demonstrates a practical attack that can be used to extract private keys from vulnerable RSA applications. In this way, a remote attacker could derive private RSA keys.

As reported in the CERT advisory:

"Using statistical techniques and carefully measuring the amount of time required to complete an RSA decryption operation, an attacker can recover one of the factors (q) of the RSA key. With the public key and the factor q, the attacker can compute the private key. As noted in the VMM/attestation example in section 4 of the paper, applications that perform RSA encryption (signing) operations may also be vulnerable. Similar types of timing attacks are discussed in CERT Advisory CA-1998-07, a paper by Daniel Bleichenbacher et al., and a paper by Paul Kocher.

The paper recommends a defense called "RSA blinding" that introduces an additional random component to the RSA calculation and makes timing information unusable to attackers. It appears that many cryptographic libraries and applications either do not implement RSA blinding or do not make use of it when it is available. RSA blinding does incur a slight performance penalty. Although the OpenSSL library used in the experiments does implement RSA blinding, it is not enabled by default. Many applications that use OpenSSL, including Apache mod_ssl, do not use RSA blinding, and are therefore vulnerable to this attack."

VanDyke Software confirmed on March 14, 2003 to CERT that SecureCRT when using SSH1 may be subject to this vulnerability (version 4.0.4 and earlier). SecureCRT 4.0.6 addresses this vulnerability. No other VanDyke Software products are subject to this vulnerability since blinding is used for SSH2 with RSA private keys. For a complete list of vendor responses, see the listing in the CERT Vulnerability Note.

This vulnerability is specific to SSH1 connections. SSH2 server connections do not share this vulnerability.

SSH2 offers substantially greater security than SSH1. VanDyke Software recommends that all SSH1 users switch to SSH2 connections if possible. Further, those users who do not have an SSH2 server currently available are encouraged to make plans to migrate to SSH2 as soon as possible.

 

Affected Software Versions

SecureCRT 4.0.4 official or earlier, SSH1 connections only
SecureCRT 3.x official, SSH1 connections only
SecureCRT 2.x official, SSH1 connections only

 

Vulnerability Fix Download

SecureCRT 4.0.9 - https://www.vandyke.com/download/securecrt/4.0/index.html

 

Technical Support

For further information on the security advisory, please contact VanDyke Software.
 

Advisory Postings

The original posting of this vulnerability was made on the CERT web site on March 25, 2003.
 

Revision History

March 25, 2003 - Vulnerability Note published.
April 3, 2003 - Vulnerability Note updated.
April 17, 2003 - Security Advisory updated.
June 19, 2003 - Security Advisory updated.
August 19, 2003 - Security Advisory updated.
October 16, 2003 - Security Advisory updated.
December 4, 2003 - Security Advisory updated.

VanDyke Software uses cookies to give you the best online experience. Before continuing to use this site, please confirm that you agree to our use of cookies. Please see our Cookie Usage for details.