search menu icon-carat-right cmu-wordmark

CERT Coordination Center


Cryptographic libraries and applications do not adequately defend against timing attacks

Vulnerability Note VU#997481

Original Release Date: 2003-03-25 | Last Revised: 2004-08-25

Overview

Cryptographic libraries and applications do not provide adequate defense against a side-channel timing attack against RSA private keys. Such an attack has been shown to be practical using currently available hardware on systems and networks with sufficiently low variance in latency.

Description

David Brumley and Dan 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. Using statistical techniques and carefully measuring the amount of time required to complete an RSA operation, an attacker can recover one of the factors (q) of the RSA key. The timing differences examined in the paper are based on whether an extra Mongtomery reduction is performed (section 2.3) and whether Karatsuba (recursive) or "normal" multiplication is used (section 2.4). 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 if the attacker can control the data to be signed.

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 Brumley and Boneh paper documents a set of experiments using currently available hardware to attack three different OpenSSL-based RSA decryption applications: a simple RSA decryption oracle, Apache/mod_ssl, and Stunnel. Under optimal conditions, a 1024-bit RSA private key was extracted in approximately two hours using ~350,000 guesses. In the context of an SSL/TLS handshake, the guesses take the form of the premaster secret (client key exchange message), and the guesses may appear to a web server as completed TCP connections and failed attempts to set up SSL/TLS sessions. The experiments were conducted both interprocess on a single machine and on a high-speed, closed network that does not accurately reflect the network conditions found on the Internet. The attack could, however, be feasible on a network with a low variance in latency such as a LAN, corporate/campus network, or Internet2/Abilene. The attack could also work against an SSL/TLS enabled web server to which the attacker has local access, such as a shared server in a co-location facility. The paper also notes that interprocess attacks against Virtual Machines (VM) running on the same physical computer could yield RSA secrets held by a trusted VM, such as a TCPA/Palladium system.

The experiments focus on RSA software implementations, OpenSSL in particular. The paper states that "most crypto acceleration cards also implement defenses against the timing attack. Consequently, network servers using these accelerator cards are not vulnerable." Any applications that perform RSA private key operations may be vulnerable: SSL/TLS-enabled network services, IPsec, Secure Shell (SSH1, ssh-agent), TCPA/Palladium, and smart cards are some examples of such applications. For specific vendor information, see the Systems Affected section below.

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.

Impact

A remote attacker could derive private RSA keys. It is important to note that the attacks described in this paper appear to be practical under certain conditions. In the case of remote attacks against SSL/TLS-enabled web servers, variance in network latency must be sufficiently low (less than 1ms), and the attacker must account for other variables such as the load on the server. A server may be more vulnerable during a period of low activity. In the case of local interprocess attacks against a web server or a VM, all the necessary conditions exist.

Solution


Upgrade or Patch

Upgrade or apply a patch as specified by your vendor. The preferred defense against this attack is to use RSA blinding, however other methods such as quantizing may also be effective. RSA blinding incurs a slight performance penalty. If an application links to a library to perform RSA operations, it is necessary for the underlying cryptographic library to support RSA blinding and for the application to make use of it.

Monitor RSA applications

Monitor RSA applications for signs of attack. In the case of an attack against SSL/TLS web servers, logs may show a relatively high number of network connections and failed attempts to establish SSL/TLS sessions.

Vendor Information

997481
Expand all

Apple Computer Inc.

Notified:  March 12, 2003 Updated:  March 25, 2003

Status

  Vulnerable

Vendor Statement

A software update is being prepared to address this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Please see APPLE-SA-2003-03-24.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Conectiva

Notified:  March 12, 2003 Updated:  April 14, 2003

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Please see CLSA-2003:625.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Covalent

Notified:  March 12, 2003 Updated:  April 04, 2003

Status

  Vulnerable

Vendor Statement

Covalent Technologies announces the availability of patch releases for Covalent FastStart 3.x and Covalent ERS 2.x, addressing the SSL Private Key vulnerability. Covalent customers can access the downloads for their platforms at http://www.covalent.net/support/rotate.php?page=109. The patch release also addresses a number of other issues, including the Denial of Service attacked referenced at [http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0132]. Further information is available in the release notes for the patches.
All Covalent customers are urged to apply these patches as soon as possible. Covalent will also include these patches in the upcoming FastStart 3.3.3 and ERS 2.3.3 releases. Covalent customers with further questions should enter a support incident through the Covalent support console.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Crypto++

Notified:  February 25, 2003 Updated:  March 25, 2003

Status

  Vulnerable

Vendor Statement

All factoring-based public key cryptosystems (RSA, Rabin, LUC) implemented in Crypto++ version 5.0 and earlier may be vulnerable to timing attacks similar to the attacks described in the paper by Brumley and Boneh. Crypto++ users who use these cryptosystems in ways that allow observation of decryption times should upgrade to version 5.1 or later. Crypto++ version 5.1 includes additional countermeasures to timing attacks, including blinding for RSA and Rabin decryption. The latest version of Crypto++ may be downloaded from http://www.cryptopp.com.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Debian

Notified:  March 12, 2003 Updated:  April 23, 2003

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Please see DSA-288.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

F5 Networks

Notified:  March 12, 2003 Updated:  March 25, 2003

Status

  Vulnerable

Vendor Statement

F5 has determined that BIG-IP and 3-DNS software may be vulnerable to the private key attack outlined in vulnerability note VU#997481. Visit the following link for more information and security updates.

http://tech.f5.com/home/bigip/solutions/security/sol2355.html

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Foundry Networks Inc.

Notified:  March 12, 2003 Updated:  April 22, 2003

Status

  Vulnerable

Vendor Statement

Foundry's SI SSL feature is a passthrough feature only and we do not handle the SSL traffic other than forwarding it to the termination point. We are not vulnerable to this attack from an SI platform perspective.
From our Ironview perspective, Foundry is implementing the necessary SSL patch with Ironview 1.6.00 which will correct the problem.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

FreSSH

Notified:  March 12, 2003 Updated:  March 25, 2003

Status

  Vulnerable

Vendor Statement

FreSSH has a "replaceable crypto module" framework that was originally intended to let commercial users use RSA BSAFE if they wished to, rather than the OpenSSL library we used for development.

The crypto module we ship as the default uses OpenSSL with its default settings for all cryptographic operations. So the vulnerability of FreSSH to this (or any other) timing attack is exactly that of the core OpenSSL RSA operations, for whatever version of OpenSSL a given user has built FreSSH with -- or that of whatever cryptographic library the user has replaced the default OpenSSL crypto module with, if the user has done so.

We could do more to blind cryptographic operations within FreSSH itself. Code in our CVS repository already does so, so if we release a new version of FreSSH at some point in the future, that release will include further blinding of cryptographic operations.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

FreeBSD

Notified:  March 12, 2003 Updated:  March 25, 2003

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Please see FreeBSD-SA-03:06.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

GNU Libgcrypt

Notified:  February 11, 2003 Updated:  March 24, 2003

Status

  Vulnerable

Vendor Statement

Libgcrypt does not have any counter measurements as of now. We are working on a suitable solution - most likely this will require applications using Libgcrypt to enable this forthcoming feature. Note, that Libgcrypt is still flagged as work in progress. We hope for a stable version in early summer.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

GNU TLS

Notified:  April 15, 2003 Updated:  April 23, 2003

Status

  Vulnerable

Vendor Statement

Gnutls is vulnerable to this attack for the time being [2003-04-16]. The issue is being addressed within libgcrypt. RSA blinding support already exists in the libgcrypt cvs, and a proper release is expected soon.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Gentoo Linux

Updated:  April 05, 2003

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

<http://forums.gentoo.org/viewtopic.php?t=42581>

<http://forums.gentoo.org/viewtopic.php?t=43709>

<http://forums.gentoo.org/viewtopic.php?t=43711>

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Guardian Digital Inc.

Notified:  March 12, 2003 Updated:  April 05, 2003

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Please see ESA-20030320-010.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Hewlett-Packard Company

Notified:  March 12, 2003 Updated:  April 29, 2003

Status

  Vulnerable

Vendor Statement

SOURCE: Hewlett-Packard Company Software Security Response Team

RE: SSRT3518 - VU#997481

At the time of writing this document, Hewlett Packard is currently investigating the potential impact to HP's released Operating System software products for HP-UX, HP Tru64 UNIX and HP OpenVMS. It is however unlikely that this presents any significant threat where RSA (blinding) may be used for layered product applications.

Not Impacted: HP NonStop Servers (Atalla)

As further information becomes available HP will provide notice of the availability of any necessary patches through standard security bulletin announcements and be available from your normal HP Services support channel.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Please see HPSBUX0304-0255/SSRT3518.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Hitachi

Notified:  March 12, 2003 Updated:  June 13, 2003

Status

  Vulnerable

Vendor Statement

Hitachi's GR2000 gigabit router series are not vulnerable to this issue.

Hitachi Web Server is vulnerable to this issue. Fixes will be prepared shortly. If you need technical information, please contact your local Hitachi support.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

IBM

Notified:  March 12, 2003 Updated:  March 21, 2003

Status

  Vulnerable

Vendor Statement

The AIX operating system in not vulnerable to the issues discussed in Vulnerability Note VU#997481.

However, OpenSSL and mod_ssl for Apache are available for installation on AIX via the AIX Toolbox for Linux. These items are shipped "as is" and are unwarranted.

OpenSSL 9.6g-2 and mod_ssl 2.8.11-2 are vulnerable to the issues discussed in Vulnerability Note VU#997481.

The AIX Toolbox team is aware of these issues and will provide patched versions of this software in the near future.

AIX Toolbox for Linux applications can be downloaded from:

http://www6.software.ibm.com/dl/aixtbx/aixtbx-p

Please note that the patched version of OpenSSL will be 0.9.6g-3 and the patched mod_ssl will be 2.8.14-1.

IBM's vendor statement will be updated when these patches are available.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Intoto

Notified:  March 12, 2003 Updated:  March 25, 2003

Status

  Vulnerable

Vendor Statement

Intoto analyzed its iGateway Ver 3.2 implementation for the RSA timing attack documented in VU#997481, and found it vulnerable.

Patch for this vulnerability can be obtained by contacting Intoto at support@intotoinc.com.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

MandrakeSoft

Notified:  March 12, 2003 Updated:  April 04, 2003

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Please see MDKSA-2003:035.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

NetBSD

Notified:  March 12, 2003 Updated:  April 23, 2003

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Please see NetBSD-SA2003-005 and the list of patches included in NetBSD 1.6.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

OpenBSD

Notified:  March 12, 2003 Updated:  April 05, 2003

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

<http://www.openbsd.org/errata32.html#blinding>

<http://www.openbsd.org/errata31.html#blinding>

If you have feedback, comments, or additional information about this vulnerability, please send us email.

OpenPKG

Updated:  June 24, 2004

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Please see OpenPKG-SA-2003.019-openssl and OpenPKG-SA-2003.020-modssl.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

OpenSSH

Notified:  March 12, 2003 Updated:  April 15, 2003

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

<http://marc.theaimsgroup.com/?l=openbsd-announce&m=104912179501519&w=2>

Changes since OpenSSH 3.5:
============================

* RSA blinding is now used by ssh(1), sshd(8) and ssh-agent(1).
  in order to avoid potential timing attacks against the RSA keys.
  Older versions of OpenSSH have been using RSA blinding in
  ssh-keysign(1) only.

  Please note that there is no evidence that the SSH protocol is
  vulnerable to the OpenSSL/TLS timing attack described in
        http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

If you have feedback, comments, or additional information about this vulnerability, please send us email.

OpenSSL

Notified:  February 11, 2003 Updated:  April 15, 2003

Status

  Vulnerable

Vendor Statement

A patch to fix the problem, which affects all versions of OpenSSL up to and including 0.9.6i and 0.9.7a, has already been released (http://www.openssl.org/news/secadv_20030317.txt). Versions 0.9.6j and 0.9.7b will be released shortly.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Please reference OpenSSL Security Advisory [17 March 2003]. RSA blinding is enabled by default in in OpenSSL 0.9.7b and 0.9.6j.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Red Hat Inc.

Notified:  March 12, 2003 Updated:  April 01, 2003

Status

  Vulnerable

Vendor Statement

Red Hat Linux and Red Hat Enterprise Linux ship with an OpenSSL package vulnerable to these issues. Updated OpenSSL packages are available along with our advisory at the URLs below. Users of the Red Hat Network can update their systems using the 'up2date' tool.
Red Hat Enterprise Linux:

http://rhn.redhat.com/errata/RHSA-2003-102.html
Red Hat Linux:

http://rhn.redhat.com/errata/RHSA-2003-101.html

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

SGI

Notified:  March 12, 2003 Updated:  May 15, 2003

Status

  Vulnerable

Vendor Statement

-----BEGIN PGP SIGNED MESSAGE-----

SGI acknowledges receiving CERT VU#997481 and is currently investigating.
This is being tracked as SGI Bug# 883987 and Bug# 884051.
No further information is available at this time.

For the protection of all our customers, SGI does not disclose, discuss
or confirm vulnerabilities until a full investigation has occurred and any
necessary patch(es) or release streams are available for all vulnerable
and supported SGI operating systems.  Until SGI has more definitive
information to provide, customers are encouraged to assume all security
vulnerabilities as exploitable and take appropriate steps according to
local site security policies and requirements.  As further information
becomes available, additional advisories will be issued via the normal
SGI security information distribution methods including the wiretap
mailing list on http://www.sgi.com/support/security/

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBPnIEObQ4cFApAP75AQF59gQAug0YfZ4Ja0tQ8P4dXf5D8+7bUUv8u6wt
562DX4n75G1ZFW2E+QbJjSSbY33rMrMaDl7zyarZ4pGGLQFz7fQuBq0oK2y9VtV3
QfATuZF+5wk76IQuGVFEuzP8m03eA7C8hWKo9/PjsCMm/0uovF9RpEJdiLQUdRaq
MaIEhMfLQx0=
=Bu2O
-----END PGP SIGNATURE-----

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Please see SGI Security Advisory 20030501-01-I.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

SSH Communications Security

Notified:  March 12, 2003 Updated:  April 14, 2003

Status

  Vulnerable

Vendor Statement

RSA Timing Attacks in SSH Communications Security toolkit products

Security problems have been found and corrected in the following SSH toolkit products:

    • SSH IPSEC Express Toolkit (concerns only TLS option and RSA encryption use in IKE)
    • SSH Certificate/TLS Toolkit
Other SSH toolkit products are not affected.

For SSH IPSEC Express Toolkit customers:

RSA encryption is not widely used with IKE. If you use just RSA signatures for IKE authentication and do not have the TLS option, there are no security concerns and you do not need to apply the patch.

The recently appeared article, [1], presents a new timing attack on RSA operations. The attack uses statistical analysis from timing information from RSA private key operations on chosen input texts to retrieve bits from the private key. For the approach to work, a very accurate timing analysis is required, which makes the attack only feasible over local networks or between different processes on the same machine. A second prerequiste is the ability for the opponent to selectively choose a large number of bits of the input data to the private key operation. The opponent needs to be able to choose a large number (of the order 10^5 - 10^6) of such input texts.

This means the attack as presented in [1] does not apply to situations where the private key is used for generating digital signature on input data by first hashing the input data. If the owner of the private key hashes the input data, the opponent has lost the ability to choose bits in the input data to the private key operation. [If the input to the hash function can be chosen by the opponent, then the attack may still be possible for weak hash functions if the opponent can adaptively invert the hash function. For hash functions used in cryptography this is not possible, and the attack will not succeed].

In protocols such as IKE authenticated with signatures, the input data that is hashed contains random input from the owner of the private key. In this case there is no possibility for opponent to influence the input value to the private key operation and the attack will not work.

The attack is more relevant in cases where the private key is used for decryption such as in SSL/TLS. In this case, by using an active attack, the opponent can directly choose the value to be decrypted by the victim of the attack. When performing this attack the TLS negotiation will fail because the decrypted ciphertext will not have the correct PKCS1 padding. Therefore the attack is only likely to succeed in situations where the victim TLS server keeps allowing incoming connections from a source where the TLS handshake repeatedly fails.

The attack may also be relevant in IKE when authenticating using public key encryption.

The most effective prevention for this attack is well known, and is known as blinding. Essentially this consists of randomizing the input to the modular exponentation part of the RSA private key operation. The timing of the RSA decryption is then random, and this prevents timing analysis fromrevealing any key information. The effect of blinding on performance is acceptable, varying from 2%-10%.

Our IKE and TLS implementations do not at present use blinding for RSA private key decryption operations. A patch is now available from SSH.

[1] Remote Timing Attacks are Practical, by David Brumlay and Dan Boneh.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Slackware

Updated:  May 23, 2003

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Please see SSA:2003-141-05.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Sorceror Linux

Updated:  April 04, 2003

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

<http://www.securityfocus.com/archive/1/315884/2003-03-19/2003-03-25/0>

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Stonesoft

Notified:  March 12, 2003 Updated:  June 02, 2003

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

<http://www.stonesoft.com/document/art/2949.html>

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Stunnel

Updated:  March 25, 2003

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Please reference the Stunnel web site and this message on the stunnel-users mailing list.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

The SCO Group

Notified:  March 12, 2003 Updated:  March 25, 2003

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Please see CSSA-2003-014.0.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Trustix Secure Linux

Updated:  March 20, 2003

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Please see Trustix Secure Linux Security Advisory #2003-0010.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

VanDyke Software Inc.

Notified:  March 12, 2003 Updated:  April 04, 2003

Status

  Vulnerable

Vendor Statement

The following VanDyke Software products are not vulnerable to a timing attack discussed in VU#997481 because blinding is used with RSA private keys:

VShell - all versions
SecureCRT, using SSH2 - all versions
SecureFX - all versions
Entunnel - all versions

The only VanDyke Software product that is potentially vulnerable to a timing attack is SecureCRT, when SSH1 is used. A fix for SSH1 will be available soon.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

SecureCRT 4.0.5 enables RSA blinding for SSH1:


<http://www.vandyke.com/products/securecrt/history.txt>

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Wirex

Notified:  March 12, 2003 Updated:  April 08, 2003

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

<http://www.securityfocus.com/archive/1/316577/2003-03-25/2003-03-31/0>

If you have feedback, comments, or additional information about this vulnerability, please send us email.

cryptlib

Notified:  February 11, 2003 Updated:  April 04, 2003

Status

  Vulnerable

Vendor Statement

cryptlib is typically used in situations such as severely resource-constrained environments where this type of attack isn't really feasible, which has lead to (to date) zero requests from users for blinding support. Although there is blinding code present, it currently requires a manual code change for users to access. Future releases will make the blinding functionality a standard configuration option.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

eSoft

Notified:  March 12, 2003 Updated:  April 23, 2003

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

mod_ssl

Updated:  March 19, 2003

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Please see the announcement for mod_ssl 2.8.13.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Bitvise

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Not Vulnerable

Vendor Statement

Our SSH2 server and client products, WinSSHD and Tunnelier, are not vulnerable as they perform no RSA private key operations. Our SSH2 library, sshlib, is also not vulnerable as it implements RSA signatures only, with an RSA implementation which uses a different exponentiation algorithm than targeted by this attack.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Clavister

Notified:  March 12, 2003 Updated:  April 04, 2003

Status

  Not Vulnerable

Vendor Statement

Clavister Firewall: Not vulnerable

Clavister VPN Client: Not vulnerable

None of Clavister's products incorporate SSL/TLS servers. We do however implement IKE. The IKE specification incorporates a mode where the Brumley/Boneh timing attack applies: IKE with RSA encryption. No Clavister products support this mode; only RSA signatures, which is not vulnerable to this attack.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Computer Associates

Notified:  March 12, 2003 Updated:  April 07, 2003

Status

  Not Vulnerable

Vendor Statement

Computer Associates is aware of the recent success of remote timing attacks against OpenSSL. Unicenter is not susceptible to this attack.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Entrust

Notified:  March 14, 2003 Updated:  March 19, 2003

Status

  Not Vulnerable

Vendor Statement

Entrust's products use RSA blinding which the research from Stanford University recommends as an effective defense against this timing attack.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

F-Secure

Notified:  March 12, 2003 Updated:  March 25, 2003

Status

  Not Vulnerable

Vendor Statement

F-Secure SSH products are not vulnerable to RSA timing attack.

The recently appeared article, [1], presents a new timing attack on RSA operations. The attack tries to retrieve bits from the private key by statistically analyzing the timing information from RSA private key operations on chosen input texts.

As a prerequisite, the opponent/attacker must be able to selectively choose a large number of bits of the input data to the private key operation. The opponent needs to be able to choose a large number (of the order 10^5 - 10^6) of such input texts.

This means the attack as presented in [1] does not apply to situations where the private keys are used to generate digital signatures on the input data by hashing the input data first. If the owner of the private key hashes the input data, the opponent has lost the ability to choose bits in the input data to the private key operation.

In Secure Shell protocol, when authenticated with signatures, the input data that is hashed contains random input from the owner of the private key. The opponent does not have a possibility to influence the input value to the private key operation and the attack does not work.

[1] Remote Timing Attacks are Practical, by David Brumlay and Dan Boneh.
http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Fujitsu

Notified:  March 12, 2003 Updated:  April 05, 2003

Status

  Not Vulnerable

Vendor Statement

Fujitsu's UXP/V o.s. is not affected by the problem in VU#997481 because it does not support the RSA.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

GNU adns

Notified:  March 12, 2003 Updated:  April 04, 2003

Status

  Not Vulnerable

Vendor Statement

adns does not do any crypto and is not vulnerable.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

GNU glibc

Notified:  March 12, 2003 Updated:  March 25, 2003

Status

  Not Vulnerable

Vendor Statement

The GNU C Library is not vulnerable, as it does not implement or use RSA.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Global Technology Associates

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Not Vulnerable

Vendor Statement

Global Technology Associates, Inc. has examined this issue and is pleased to report this issue does not impact any versions (current and past) of the GTA firewall products.

To report potential security vulnerabilities in GTA products, send an E-mail message to: security-alert@gta.com.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

IP Filter

Notified:  March 12, 2003 Updated:  March 25, 2003

Status

  Not Vulnerable

Vendor Statement

IPFilter is not affected by this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Ingrian Networks

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Not Vulnerable

Vendor Statement

Ingrian Networks products are not susceptible to this vulnerability.

Ingrian Networks products perform RSA operations in hardware. The attack identifies bits in the key by measuring time differences in software to perform Montgomery reduction, and in the time differences between software implementations of normal and Karatsuba multiplication used to perform different parts of the RSA private key operation. RSA hardware does not have these time differences.

Additionally, Ingrian's software architecture is designed to mask any timing difference in hardware RSA operations.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Internet Initiative Japan (IIJ)

Notified:  March 12, 2003 Updated:  April 05, 2003

Status

  Not Vulnerable

Vendor Statement

IIJ SEIL/neu routers:

All products are not vulnerable.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

MacSSH

Notified:  March 12, 2003 Updated:  April 14, 2003

Status

  Not Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

MacSSH is based on lsh. lsh only implements SSH version 2. SSH 2 is not vulnerable to this attack since the attacker cannot adequately control input to the RSA signing operation.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Microsoft Corporation

Notified:  February 11, 2003 Updated:  March 19, 2003

Status

  Not Vulnerable

Vendor Statement

Microsoft has determined that our implementation of this technology is not vulnerable to the two attacks described in this paper. We are continuing to assess the implications of the paper.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Mozilla

Updated:  March 18, 2003

Status

  Not Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Netfilter

Notified:  March 12, 2003 Updated:  April 14, 2003

Status

  Not Vulnerable

Vendor Statement

The netfilter/iptables subsystem does not implement any cryptographic functionality and is thus not affected by any RSA vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Netscape Communications Corporation

Notified:  February 11, 2003 Updated:  April 11, 2003

Status

  Not Vulnerable

Vendor Statement

The CERT Coordination Center has recently released Vulnerability Note VU#997481, which indicates that some cryptographic libraries and applications do not provide adequate defense against timing attacks on RSA private keys. The Netscape cryptographic libraries and the application products (both client and server software) based on them are not susceptible to this vulnerability. In particular, the Netscape libraries and applications use RSA blinding, which the CERT Note describes as the preferred defense against this vulnerability.

Netscape takes all security and privacy matters very seriously and has been using RSA blinding in its cryptographic libraries since 1997 to prevent timing vulnerabilities against private keys.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

RSA Security

Notified:  February 11, 2003 Updated:  March 25, 2003

Status

  Not Vulnerable

Vendor Statement

RSA BSAFE Crypto-C software includes support for blinding. Blinding must be explicitly enabled and used by the developer (please see the product documentation for details).

RSA BSAFE Cert-C software uses RSA BSAFE Crypto-C as its cryptographic library, but RSA BSAFE Cert-C uses the non-blinding version of RSA by default. The blinding option can be enabled in the Cryptographic Service Provider. Please contact RSA Security Support (telephone numbers posted at http://www.rsasecurity.com/support/contact.html) for more information about making this change.

The next versions of these two RSA BSAFE products will include additional blinding options.

To protect against various timing based attacks on the SSL protocol, RSA BSAFE SSL-C 2.3.1 software includes protection, such as the use of blinding of RSA operations, enabled by default. A developer can disable blinding if the use of the RSA BSAFE SSL-C software will not expose the application to such a timing attack (please refer to the product documentation for details).

RSA Security is addressing blinding across the products in the RSA BSAFE line. We will provide status updates for RSA BSAFE customers via SecurCare Notes to customers who register to receive product announcements at RSA SecurCare Online (https://knowledge.rsasecurity.com/).

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Symantec Corporation

Notified:  March 12, 2003 Updated:  April 14, 2003

Status

  Not Vulnerable

Vendor Statement

While some Symantec products do use RSA libraries, it has been determined that none are currently vulnerable. This is due to the method in which these libraries are being used.

To insure that our products remain secure, Symantec will apply the corrective specified by RSA.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

TTSSH/TeraTerm

Notified:  March 12, 2003 Updated:  March 25, 2003

Status

  Not Vulnerable

Vendor Statement

TTSSH is not vulnerable because it's only a client application. There is no way to induce TTSSH to perform hundreds of thousands of private key operations.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

ZyXEL

Notified:  March 12, 2003 Updated:  April 04, 2003

Status

  Not Vulnerable

Vendor Statement

ZyXEL's present implementations don't utilize RSA algorithm. So there is no related issue currently.

In the second quarter of 2003, ZyWALL will support RSA signatures for IKE authentication which has no security concerns to this vulnerability either. This is because when IKE authenticated with RSA signatures, the input data that is hashed contains random input from the owner of the private key. In this case there is no possibility for opponent to influence the input value to the private key operation and the attack will not work.

But ZyWALL will leverage an RSA blinding procedure at the first moment of the release which can prevent this vulnerability if necessary in the future. The blinding procedure consists of randomizing the input to the modular exponentiation part of the RSA private key operation. The timing of the RSA decryption is then random, and thus prevents timing analysis from revealing any key information.

So ZyXEL's devices are immune to this vulnerability, #997481 now and hereafter.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

iPlanet

Updated:  March 21, 2003

Status

  Not Vulnerable

Vendor Statement

The SunONE products rely upon NSS for their SSL funtionality.
NSS is not and has not been vulnerable. NSS implements RSA blinding as suggested in the research paper here:

http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

lsh

Notified:  March 12, 2003 Updated:  April 05, 2003

Status

  Not Vulnerable

Vendor Statement

The SSH-2 protocol does not use RSA encryption, only RSA signatures. The attacker does not get much control over the input to the RSA private key operation. LSH is therefore *not* vulnerable to the described timing attack.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

3Com

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

AT&T

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Alcatel

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Apache

Notified:  March 12, 2003 Updated:  April 04, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

Apache 2.0.x relies on OpenSSL to perform SSL/TLS operations, so a patched version of OpenSSL is required to defend against this attack on Apache 2.0.x servers. Apache 1.3.x uses mod_ssl to perform SSL/TLS operations, so an updated version of mod_ssl is required to defend against this attack on Apache 1.3.x servers.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Apache-SSL

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Avaya

Notified:  March 12, 2003 Updated:  March 25, 2003

Status

  Unknown

Vendor Statement

Avaya is aware of the vulnerability note and is investigating.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

BlueCat Networks

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

BorderWare

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Check Point

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Cisco Systems Inc.

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Cray Inc.

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

D-Link Systems

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Data General

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

FreeS/WAN

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Intel

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Internet Software Consortium

Notified:  March 12, 2003 Updated:  March 25, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Intersoft International Inc.

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Juniper Networks

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

KAME Project

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Lotus Software

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Lucent Technologies

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Massachusetts Institute of Technology (MIT)

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Men&Mice

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

MetaSolv Software Inc.

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

MontaVista Software

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Multi-Tech Systems Inc.

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

NEC Corporation

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

National Center for Supercomputing Applications (NCSA)

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

National Institute of Standards and Technology (NIST)

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

NetScreen

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Netcomposite

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Nettle

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Network Appliance

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Network Associates

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Nixu

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Nokia

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Nominum

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Nortel Networks

Notified:  March 12, 2003 Updated:  March 12, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Novell

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Openwall GNU/*/Linux

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Pragma Systems

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

PuTTY

Notified:  March 12, 2003 Updated:  April 04, 2003

Status

  Unknown

Vendor Statement

Current versions of PuTTY might well not be vulnerable to this attack _at all_, as a consequence of not using any of the RSA optimisations that apparently provide timing loopholes. However, this is not certain.

    • Future versions of PuTTY will employ RSA blinding, so that even if I do implement any optimisations they will still not be vulnerable.
    • If a user of a current PuTTY wants to make doubly certain they are safe from this attack, they should ensure they are using SSH2, and they should not forward their agent to any machine whose sysadmin might be untrustworthy. However, they should have been doing both of these (_especially_ the latter) already.
    • In the absence of agent forwarding, an SSH1 client is not practically vulnerable, and I think an SSH2 client is not even theoretically vulnerable.
    • With agent forwarding, an SSH1 client is vulnerable, but an SSH2 client might well not be (unless the attack can be revised to cope with serious restrictions on ciphertext choice).
    • The practical risk of this attack being used against agent forwarding is minimal, since any attacker in a position to do so already has much easier attacks open to them.

My first reason for believing the risk is minimal is the nature of the actual attack.

The bulk of Brumley and Boneh's paper details OpenSSL's use of the Chinese Remainder Theorem and the Montgomery and Karatsuba techniques to optimise its RSA implementation for speed, and it focuses its analysis on specific timing loopholes opened by these particular techniques. PuTTY uses none of these techniques - my RSA implementation has always been a completely naive single modpow, with no fancy tricks in the multiplication either (not for any security reasons - I just never got round to making it go any faster!). So the attack _as described_ will almost certainly not work against PuTTY's RSA implementation. However, it might be that a related attack might be made practical against an RSA implementation which does not use these techniques, so that alone does not justify complacence.

My second reason for believing the risk is minimal is to do with the nature of PuTTY, and indeed SSH clients in general.

The attack described by Brumley and Boneh is a chosen-ciphertext attack, which is (as I understand it) practical against any piece of code which will perform a private key operation on arbitrary ciphertext sent to it and give back some indication of how long the operation took. Furthermore, the piece of code under attack has to be willing to perform millions of these operations in a reasonably short time to make the attack practical.

PuTTY implements the client side only of the SSH protocol. In the transport layer of this protocol, all the risk is on the server side:  any SSH1 server will do RSA decryption on ciphertext sent by the client, and SSH2 servers may do RSA signing on a shared secret resulting from a key exchange. So an SSH1 server may very well be vulnerable, but an SSH2 server is unlikely to be (since the client cannot control the data being signed). Any SSH _client_, however, does only public key operations in the transport layer, so it is not vulnerable at all.

That still leaves key operations in the authentication layer, though. Again, SSH1 authentication is more dangerous here, since it is based on the server sending a challenge (RSA ciphertext) which the client must then prove it has successfully decrypted. So if I were to make millions of SSH1 connections to the same server, using public-key authentication with the same key under the same network conditions, then the server could _conceivably_ implement a timing attack and derive my private key. But in practice people generally make one or two connections at a time, not millions.

SSH2 public key authentication is inherently safer, since it's signature-based: the client invents some data to be signed and then does an RSA private key operation on it, and the server's only input into that data is the shared secret from the key exchange, which it cannot control due to the client-side random input.

The most plausible way I can think of to mount a timing attack against an SSH client involves agent forwarding, in which the SSH client allows an SSH server to present chosen ciphertexts to its authentication agent for decryption (SSH1) or signing (SSH2). This would allow the server an automated means of requesting the millions of decryptions required to execute the attack. I'm not sure how well it would work in SSH2; although the server would get free choice of 20 bytes of the ciphertext, the rest would always be prescribed signature padding and I don't know whether the attack could still work under that restriction.

However, I don't believe attacks against a forwarded SSH agent are a credible danger, simply because if the sysadmin of your SSH server is abusing your forwarded agent then you're doomed _anyway_ - instead of performing a million decryptions to deduce your private key, he'd have been more likely to just perform _one_ and use it to authenticate to one of your other accounts. All agent forwarding is done on the assumption that the sysadmin of the server is trusted not to do this sort of thing, so the additional risk is not great.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Redback Networks Inc.

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Riverstone Networks

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

SSLeay

Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

SafeNet

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Secure Computing Corporation

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

SecureWorx

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Sequent

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Sony Corporation

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

SuSE Inc.

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Sun Microsystems Inc.

Notified:  February 28, 2003 Updated:  March 03, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Unisys

Notified:  March 12, 2003 Updated:  March 19, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

WatchGuard

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Wind River Systems Inc.

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

djbdns

Notified:  March 12, 2003 Updated:  March 17, 2003

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.


CVSS Metrics

Group Score Vector
Base N/A N/A
Temporal N/A N/A
Environmental N/A

References

Credit

This vulnerability is documented in a research paper written by David Brumley and Dan Boneh of Stanford University.

This document was written by Art Manion.

Other Information

CVE IDs: CVE-2003-0147
Severity Metric: 9.42
Date Public: 2003-03-14
Date First Published: 2003-03-25
Date Last Updated: 2004-08-25 17:59 UTC
Document Revision: 66

Sponsored by the Department of Homeland Security Office of Cybersecurity and Communications.