[UNIX] Timing Attack on OpenSSL (OpenSSL Private Key Disclosure)

• Previous message: support@securiteam.com: "[EXPL] PGP4Pine Exploit Mail Generator"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

From: support@securiteam.com
To: list@securiteam.com
Date: 17 Mar 2003 18:59:46 +0200

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

In the US?

Contact Beyond Security at our new California office
housewarming rates on automated network vulnerability
scanning. We also welcome ISPs and other resellers!

Please contact us at: 323-882-8286 or ussales@beyondsecurity.com
- - - - - - - - -

  Timing Attack on OpenSSL (OpenSSL Private Key Disclosure)
------------------------------------------------------------------------

SUMMARY

Researchers have discovered a timing attack on RSA keys, to which OpenSSL
is generally vulnerable, unless RSA blinding has been turned on
(Typically, it will not have been, because it is not easily possible to do
so when using OpenSSL to provide SSL or TLS).

DETAILS

Vulnerable systems:
 * OpenSSL v0.9.7a and 0.9.6i

David Brumley and Dan Boneh, researchers at Stanford University, have
written a paper that demonstrates practical attacks that can be used to
extract private keys from vulnerable RSA decryption applications. Using
statistical techniques and carefully measuring the amount of time required
to complete an RSA decryption operation on known cyphertext, an attacker
can recover one of the factors (q) of the RSA key. With the public key and
the factor q, the attacker can compute the private key.

Similar types of timing attacks are discussed in CERT Advisory CA-1998-07,
a paper by Daniel Bleichenbacher et al., and a paper by Paul Kocher.

The paper documents a set of experiments using widely available hardware
to attack a simplified model of an SSL/TLS-enabled web server. The
researchers were able to extract a 1024-bit RSA private key from the model
RSA decryption server in approximately two hours. The attack requires
~350,000 samples, which to a web server may appear as network connections
and failed attempts to set up SSL/TLS sessions. The experiments were
conducted on a high-speed, closed network that does not accurately reflect
the network conditions found on the Internet. The attacks could, however,
be feasible on a network with a low variance in latency such as a LAN,
corporate/campus network, or Internet2/Abilene. The attacks could also be
feasible against production SSL-enabled web servers. The paper also notes
that inter-process attacks against Virtual Machines (VM) running on the
same physical computer could yield RSA secrets held by a trusted VM,
violating the TCPA/Palladium security model.

The paper discusses a defense called "RSA blinding" that introduces an
additional random component to the decryption process and makes timing
information unusable to attackers. It appears that many cryptographic
libraries and applications that may use those libraries either do not
implement RSA blinding or do not make use of it when it is available in
the underlying libraries. RSA blinding does incur a moderate performance
penalty. Although the OpenSSL library does implement RSA blinding, many
applications that use OpenSSL, including Apache mod_ssl, do not use this
feature, and are therefore vulnerable to timing attacks.

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 (> 1ms)
and the load on the server must be accounted for by the attacker. A server
may be vulnerable during a period of low activity. In the case of local
inter-process attacks against a VM, or, all the necessary conditions
exist. Any applications that perform RSA private key operations
(decryption, signing) may be vulnerable: SSL/TLS-enabled network services,
IPSec, Secure Shell (SSH), and smart cards are some examples of such
applications.

Solution:
Upgrade or Patch
Upgrade or apply a patch as specified by your vendor. The preferred
defense is to use RSA blinding, however other methods such as quantizing
can be used to reduce or eliminate the information disclosed by timing.
These defenses do incur performance penalties - 2-10% in the case of RSA
blinding. In order to use RSA blinding to defend against these types of
timing attacks, it is necessary for the underlying cryptographic library
to support RSA blinding and for the application to make use of it.

Use larger RSA keys
At the present (February 2003), the attacks are practical against 1024-bit
RSA keys.

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

Authenticate clients
In the case of sensitive web applications, require clients to use strong
authentication (X.509 client certificates). While this will not prevent
attacks, it will limit and identify the possible sources of attacks.

Apache Patch:
The enclosed patch switches blinding on by default. Applications that wish
to can remove the blinding with RSA_blinding_off(), but this is not
generally advised. It is also possible to disable it completely by
defining OPENSSL_NO_FORCE_RSA_BLINDING at compile-time.

The performance impact of blinding appears to be small (a few percent).

This problem affects many applications using OpenSSL, in particular,
almost all SSL-enabled Apaches. You should rebuild and reinstall OpenSSL,
and all affected applications.

Apache.org strongly advise upgrading OpenSSL in all cases, as a
precaution.

Index: crypto/rsa/rsa_eay.c
 ===================================================================
RCS file: /e/openssl/cvs/openssl/crypto/rsa/rsa_eay.c,v
retrieving revision 1.28.2.3
diff -u -r1.28.2.3 rsa_eay.c
--- crypto/rsa/rsa_eay.c 30 Jan 2003 17:37:46 -0000 1.28.2.3
+++ crypto/rsa/rsa_eay.c 16 Mar 2003 10:34:13 -0000
@@ -195,6 +195,25 @@
  return(r);
  }
 
+static int rsa_eay_blinding(RSA *rsa, BN_CTX *ctx)
+ {
+ int ret = 1;
+ CRYPTO_w_lock(CRYPTO_LOCK_RSA);
+ /* Check again inside the lock - the macro's check is racey */
+ if(rsa->blinding == NULL)
+ ret = RSA_blinding_on(rsa, ctx);
+ CRYPTO_w_unlock(CRYPTO_LOCK_RSA);
+ return ret;
+ }
+
+#define BLINDING_HELPER(rsa, ctx, err_instr) \
+ do { \
+ if(((rsa)->flags & RSA_FLAG_BLINDING) && \
+ ((rsa)->blinding == NULL) && \
+ !rsa_eay_blinding(rsa, ctx)) \
+ err_instr \
+ } while(0)
+
 /* signing */
 static int RSA_eay_private_encrypt(int flen, const unsigned char *from,
       unsigned char *to, RSA *rsa, int padding)
@@ -239,8 +258,8 @@
  goto err;
  }
 
- if ((rsa->flags & RSA_FLAG_BLINDING) && (rsa->blinding == NULL))
- RSA_blinding_on(rsa,ctx);
+ BLINDING_HELPER(rsa, ctx, goto err;);
+
  if (rsa->flags & RSA_FLAG_BLINDING)
  if (!BN_BLINDING_convert(&f,rsa->blinding,ctx)) goto err;
 
@@ -318,8 +337,8 @@
  goto err;
  }
 
- if ((rsa->flags & RSA_FLAG_BLINDING) && (rsa->blinding == NULL))
- RSA_blinding_on(rsa,ctx);
+ BLINDING_HELPER(rsa, ctx, goto err;);
+
  if (rsa->flags & RSA_FLAG_BLINDING)
  if (!BN_BLINDING_convert(&f,rsa->blinding,ctx)) goto err;
 
Index: crypto/rsa/rsa_lib.c
 ===================================================================
RCS file: /e/openssl/cvs/openssl/crypto/rsa/rsa_lib.c,v
retrieving revision 1.30.2.2
diff -u -r1.30.2.2 rsa_lib.c
--- crypto/rsa/rsa_lib.c 30 Jan 2003 17:37:46 -0000 1.30.2.2
+++ crypto/rsa/rsa_lib.c 16 Mar 2003 10:34:13 -0000
@@ -72,7 +72,13 @@
 
 RSA *RSA_new(void)
  {
- return(RSA_new_method(NULL));
+ RSA *r=RSA_new_method(NULL);
+
+#ifndef OPENSSL_NO_FORCE_RSA_BLINDING
+ r->flags|=RSA_FLAG_BLINDING;
+#endif
+
+ return r;
  }
 
 void RSA_set_default_method(const RSA_METHOD *meth)

ADDITIONAL INFORMATION

Full paper:
 <http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf>
http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

The information has been provided by <mailto:dbrumley@stanford.edu> David
Brumley, <mailto:dabo@cs.stanford.edu> Dan Boneh,
<mailto:hack4life@hushmail.com> hack4life and <mailto:ben@algroup.co.uk>
Ben Laurie.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

• Previous message: support@securiteam.com: "[EXPL] PGP4Pine Exploit Mail Generator"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]