Lucene search

CERTVU:997481

HistoryMar 25, 2003 - 12:00 a.m.

Cryptographic libraries and applications do not adequately defend against timing attacks

2003-03-2500:00:00

www.kb.cert.org

CVSS2

Attack Vector

NETWORK

Attack Complexity

LOW

Authentication

NONE

Confidentiality Impact

PARTIAL

Integrity Impact

NONE

Availability Impact

NONE

AV:N/AC:L/Au:N/C:P/I:N/A:N

EPSS

0.902

Percentile

98.9%

JSON

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

Filter by status: All Affected Not Affected Unknown

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

F5 Networks __ Affected

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

Status

Affected

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

Foundry Networks Inc. __ Affected

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

Status

Affected

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

FreSSH __ Affected

<<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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

Guardian Digital Inc. __ Affected

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

Status

Affected

Vendor Statement

We have not received a statement from the vendor.

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

Hewlett-Packard Company __ Affected

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

Status

Affected

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

Hitachi __ Affected

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

Status

Affected

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

IBM __ Affected

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

Status

Affected

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

Intoto __ Affected

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

Status

Affected

Vendor Statement

Vendor Statement

We have not received a statement from the vendor.

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

OpenPKG __ Affected

Updated: June 24, 2004

Status

Affected

Vendor Statement

We have not received a statement from the vendor.

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

OpenSSH __ Affected

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

Status

Affected

Vendor Statement

We have not received a statement from the vendor.

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

OpenSSL __ Affected

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

Status

Affected

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

Red Hat Inc. __ Affected

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

Status

Affected

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

SGI __ Affected

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

Status

Affected

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

SSH Communications Security __ Affected

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

Status

Affected

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.

Affected

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

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

Clavister __ Not Affected

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

Status

Not Affected

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

Computer Associates __ Not Affected

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

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

Fujitsu __ Not Affected

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

Status

Not Affected

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

GNU adns __ Not Affected

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

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

IP Filter __ Not Affected

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

Status

Not Affected

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

Ingrian Networks __ Not Affected

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

Status

Not Affected

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

Internet Initiative Japan (IIJ) __ Not Affected

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

Status

Not Affected

Vendor Statement

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

RSA Security __ Not Affected

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

Status

Not Affected

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

Symantec Corporation __ Not Affected

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

Status

Not Affected

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

TTSSH/TeraTerm __ Not Affected

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

Status

Not Affected

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

ZyXEL __ Not Affected

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

Status

Not Affected

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

iPlanet __ Not Affected

Updated: March 21, 2003

Status

Not Affected

Vendor Statement

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.`

We have not received a statement from the vendor.

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](<mailto:[email protected]?Subject=VU%23997481 Feedback>).

View all 116 vendors __View less vendors __