PuTTY Information for VU#997481

Cryptographic libraries and applications do not adequately defend against timing attacks


Unknown. If you are the vendor named above, please contact us to update your status.

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.

Vendor References



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.