Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 04, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
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.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 25, 2003
Affected
A software update is being prepared to address this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Please see APPLE-SA-2003-03-24.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 25, 2003
Unknown
Avaya is aware of the vulnerability note and is investigating.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 17, 2003
Not Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 04, 2003
Not Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 07, 2003
Not Affected
Computer Associates is aware of the recent success of remote timing attacks against OpenSSL. Unicenter is not susceptible to this attack.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 14, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Please see CLSA-2003:625.
Notified: March 12, 2003 Updated: April 04, 2003
Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: February 11, 2003 Updated: April 04, 2003
Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: February 25, 2003 Updated: March 25, 2003
Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 23, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Please see DSA-288.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 14, 2003 Updated: March 19, 2003
Not Affected
Entrust's products use RSA blinding which the research from Stanford University recommends as an effective defense against this timing attack.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 23, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 25, 2003
Affected
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
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 22, 2003
Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 25, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Please see FreeBSD-SA-03:06.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 25, 2003
Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 25, 2003
Not Affected
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
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 05, 2003
Not Affected
Fujitsu's UXP/V o.s. is not affected by the problem in VU#997481 because it does not support the RSA.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Updated: April 05, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Notified: March 12, 2003 Updated: March 19, 2003
Not Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 04, 2003
Not Affected
adns does not do any crypto and is not vulnerable.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 25, 2003
Not Affected
The GNU C Library is not vulnerable, as it does not implement or use RSA.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: February 11, 2003 Updated: March 24, 2003
Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 15, 2003 Updated: April 23, 2003
Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 05, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Please see ESA-20030320-010.
Notified: March 12, 2003 Updated: April 29, 2003
Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
Please see HPSBUX0304-0255/SSRT3518.
Notified: March 12, 2003 Updated: June 13, 2003
Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 21, 2003
Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Not Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 05, 2003
Not Affected
IIJ SEIL/neu routers: All products are not vulnerable.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 25, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 25, 2003
Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 25, 2003
Not Affected
IPFilter is not affected by this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Updated: March 21, 2003
Not Affected
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
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 05, 2003
Not Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 14, 2003
Not Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
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.
Notified: March 12, 2003 Updated: April 04, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Please see MDKSA-2003:035.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: February 11, 2003 Updated: March 19, 2003
Not Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Updated: March 19, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Please see the announcement for mod_ssl 2.8.13.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Updated: March 18, 2003
Not Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 23, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Please see NetBSD-SA2003-005 and the list of patches included in NetBSD 1.6.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 14, 2003
Not Affected
The netfilter/iptables subsystem does not implement any cryptographic functionality and is thus not affected by any RSA vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: February 11, 2003 Updated: April 11, 2003
Not Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 12, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 05, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Updated: June 24, 2004
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Please see OpenPKG-SA-2003.019-openssl and OpenPKG-SA-2003.020-modssl.
Notified: March 12, 2003 Updated: April 15, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Notified: February 11, 2003 Updated: April 15, 2003
Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
Please reference OpenSSL Security Advisory [17 March 2003]. RSA blinding is enabled by default in in OpenSSL 0.9.7b and 0.9.6j.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 04, 2003
Unknown
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 01, 2003
Affected
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
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: February 11, 2003 Updated: March 25, 2003
Not Affected
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/).
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: May 15, 2003
Affected
-----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-----
The vendor has not provided us with any further information regarding this vulnerability.
Please see SGI Security Advisory 20030501-01-I.
Updated: May 23, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Please see SSA:2003-141-05.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Updated: April 04, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Notified: March 12, 2003 Updated: April 14, 2003
Affected
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. http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: June 02, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Updated: March 25, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Please reference the Stunnel web site and this message on the stunnel-users mailing list.
Notified: February 28, 2003 Updated: March 03, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 14, 2003
Not Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 25, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Please see CSSA-2003-014.0.
Updated: March 20, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Please see Trustix Secure Linux Security Advisory #2003-0010.
Notified: March 12, 2003 Updated: March 25, 2003
Not Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 19, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 04, 2003
Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
SecureCRT 4.0.5 enables RSA blinding for SSH1:
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: March 17, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: March 12, 2003 Updated: April 08, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Notified: March 12, 2003 Updated: April 04, 2003
Not Affected
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.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.