Fwd: OpenSSL Security Advisory: Timing-based attacks on SSL/TLS with CBC encryption

Robert Olson olson at mcs.anl.gov
Thu Feb 20 08:31:01 CST 2003


good example of the subtlty of attacks that can be launched...

>Delivered-To: openssl-announce-l at master.openssl.org
>X-Original-To: openssl-announce at openssl.org
>Delivered-To: openssl-announce at openssl.org
>X-Original-To: openssl-announce at openssl.org
>Date: Thu, 20 Feb 2003 12:45:10 +0100
>From: Bodo Moeller <bodo at openssl.org>
>To: openssl-announce at openssl.org
>Subject: OpenSSL Security Advisory: Timing-based attacks on SSL/TLS with 
>CBC encryption
>User-Agent: Mutt/1.2.5i
>Sender: owner-openssl-announce at openssl.org
>Reply-To: openssl-users at openssl.org
>X-Sender: Bodo Moeller <bodo at openssl.org>
>X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.21
>X-Spam-Level:
>
>OpenSSL Security Advisory [19 February 2003]
>
>Timing-based attacks on SSL/TLS with CBC encryption
>===================================================
>
>CONTENTS
>
>  - Vulnerability
>  - Source code patch [*]
>  - Acknowledgement
>  - References
>
>[*] OpenSSL 0.9.6i and OpenSSL 0.9.7a do not require this patch.
>
>The source code of OpenSSL 0.9.6i and OpenSSL 0.9.7a is available as
>files openssl-0.9.6i.tar.gz and openssl-0.9.7a.tar.gz from
>
>      ftp://ftp.openssl.org/source;type=d
>
>(If you were previously using an OpenSSL 0.9.6* "engine" release and
>cannot upgrade to OpenSSL 0.9.7a, obtain file
>openssl-engine-0.9.6i.tar.gz instead.  With OpenSSL 0.9.7, the
>"engine" framework has become part of the standard distribution.)
>
>If you are using a pre-compiled OpenSSL package, please look for update
>information from the respective software distributor.  The OpenSSL
>group itself does not distribute OpenSSL binaries.
>
>
>Vulnerability
>-------------
>
>In an upcoming paper, Brice Canvel (EPFL), Alain Hiltgen (UBS), Serge
>Vaudenay (EPFL), and Martin Vuagnoux (EPFL, Ilion) describe and
>demonstrate a timing-based attack on CBC ciphersuites in SSL and TLS.
>
>The attack assumes that multiple SSL or TLS connections involve a
>common fixed plaintext block, such as a password.  An active attacker
>can substitute specifically made-up ciphertext blocks for blocks sent
>by legitimate SSL/TLS parties and measure the time until a response
>arrives: SSL/TLS includes data authentication to ensure that such
>modified ciphertext blocks will be rejected by the peer (and the
>connection aborted), but the attacker may be able to use timing
>observations to distinguish between two different error cases, namely
>block cipher padding errors and MAC verification errors.  This is
>sufficient for an adaptive attack that finally can obtain the complete
>plaintext block.
>
>OpenSSL version since 0.9.6c supposedly treat block cipher padding
>errors like MAC verification errors during record decryption
>(see http://www.openssl.org/~bodo/tls-cbc.txt), but MAC verification
>was still skipped after detection of a padding error, which allowed
>the timing attack.  (Note that it is likely that other SSL/TLS
>implementations will have similar problems.)
>
>OpenSSL 0.9.6i and 0.9.7a perform a MAC computation even if incorrrect
>block cipher padding has been found to minimize information leaked via
>timing.  For earlier versions starting with 0.9.6e, the enclosed
>security patch can be used.
>
>
>Source code patch
>-----------------
>
>If upgrading to OpenSSL 0.9.7a (the recommended version) or to OpenSSL
>0.9.6i is not immediately possible, the following patch should be
>applied to the OpenSSL source code tree.  The patch is compatible
>with OpenSSL 0.9.6e and later.
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>--- ../openssl-0.9.6h/CHANGES   Thu Dec  5 22:40:48 2002
>+++ ./CHANGES   Tue Feb 19 00:00:00 2003
>@@ -1,3 +1,19 @@
>+ Change from security patch  [19 Feb 2003]
>+
>+ (Please consider installing OpenSSL 0.9.7a or OpenSSL 0.9.6i.
>+ These versions already include this change; do not try to apply
>+ the patch to them!)
>+
>+  *) In ssl3_get_record (ssl/s3_pkt.c), minimize information leaked
>+     via timing by performing a MAC computation even if incorrrect
>+     block cipher padding has been found.  This is a countermeasure
>+     against active attacks where the attacker has to distinguish
>+     between bad padding and a MAC verification error. (CAN-2003-0078)
>+
>+     [Bodo Moeller; problem pointed out by Brice Canvel (EPFL),
>+     Alain Hiltgen (UBS), Serge Vaudenay (EPFL), and
>+     Martin Vuagnoux (EPFL, Ilion)]
>+
>
>   OpenSSL CHANGES
>   _______________
>--- ../openssl-0.9.6h/ssl/s3_pkt.c      Mon May  6 12:42:56 2002
>+++ ./ssl/s3_pkt.c      Wed Feb 18 00:00:00 2003
>@@ -238,6 +238,8 @@
>         unsigned int mac_size;
>         int clear=0;
>         size_t extra;
>+       int decryption_failed_or_bad_record_mac = 0;
>+       unsigned char *mac = NULL;
>
>         rr= &(s->s3->rrec);
>         sess=s->session;
>@@ -353,8 +355,11 @@
>                         /* SSLerr() and ssl3_send_alert() have been called */
>                         goto err;
>
>-               /* otherwise enc_err == -1 */
>-               goto decryption_failed_or_bad_record_mac;
>+               /* Otherwise enc_err == -1, which indicates bad padding
>+               * (rec->length has not been changed in this case).
>+               * To minimize information leaked via timing, we will perform
>+               * the MAC computation anyway. */
>+               decryption_failed_or_bad_record_mac = 1;
>                 }
>
>  #ifdef TLS_DEBUG
>@@ -380,28 +385,46 @@
> 
>SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_PRE_MAC_LENGTH_TOO_LONG);
>                         goto f_err;
>  #else
>-                       goto decryption_failed_or_bad_record_mac;
>+                       decryption_failed_or_bad_record_mac = 1;
>  #endif
>                         }
>                 /* check the MAC for rr->input (it's in mac_size bytes at 
> the tail) */
>-               if (rr->length < mac_size)
>+               if (rr->length >= mac_size)
>                         {
>+                       rr->length -= mac_size;
>+                       mac = &rr->data[rr->length];
>+                       }
>+               else
>+                       {
>+                       /* record (minus padding) is too short to contain 
>a MAC */
>  #if 0 /* OK only for stream ciphers */
>                         al=SSL_AD_DECODE_ERROR;
>                         SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_LENGTH_TOO_SHORT);
>                         goto f_err;
>  #else
>-                       goto decryption_failed_or_bad_record_mac;
>+                       decryption_failed_or_bad_record_mac = 1;
>+                       rr->length = 0;
>  #endif
>                         }
>-               rr->length-=mac_size;
>                 i=s->method->ssl3_enc->mac(s,md,0);
>-               if (memcmp(md,&(rr->data[rr->length]),mac_size) != 0)
>+               if (mac == NULL || memcmp(md, mac, mac_size) != 0)
>                         {
>-                       goto decryption_failed_or_bad_record_mac;
>+                       decryption_failed_or_bad_record_mac = 1;
>                         }
>                 }
>
>+       if (decryption_failed_or_bad_record_mac)
>+               {
>+               /* A separate 'decryption_failed' alert was introduced 
>with TLS 1.0,
>+               * SSL 3.0 only has 'bad_record_mac'.  But unless a decryption
>+               * failure is directly visible from the ciphertext anyway,
>+               * we should not reveal which kind of error occured -- this
>+               * might become visible to an attacker (e.g. via a logfile) */
>+               al=SSL_AD_BAD_RECORD_MAC;
>+ 
>SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC);
>+               goto f_err;
>+               }
>+
>         /* r->length is now just compressed */
>         if (s->expand != NULL)
>                 {
>@@ -443,19 +466,12 @@
>
>         return(1);
>
>-decryption_failed_or_bad_record_mac:
>-       /* Separate 'decryption_failed' alert was introduced with TLS 1.0,
>-       * SSL 3.0 only has 'bad_record_mac'.  But unless a decryption
>-       * failure is directly visible from the ciphertext anyway,
>-       * we should not reveal which kind of error occured -- this
>-       * might become visible to an attacker (e.g. via logfile) */
>-       al=SSL_AD_BAD_RECORD_MAC;
>- 
>SSLerr(SSL_F_SSL3_GET_RECORD,SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC);
>  f_err:
>         ssl3_send_alert(s,SSL3_AL_FATAL,al);
>  err:
>         return(ret);
>         }
>+const char *CAN_2003_0078_patch_ID="CAN-2003-0078 patch 2003-02-19";
>
>  static int do_uncompress(SSL *ssl)
>         {
><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
>
>Acknowledgement
>---------------
>
>We thank Brice Canvel, Alain Hiltgen, Serge Vaudenay, and Martin
>Vuagnoux for informing us about this vulnerability.
>
>
>References
>----------
>
>The Common Vulnerabilities and Exposures project (cve.mitre.org) has
>assigned the name CAN-2003-0078 to this issue:
>http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0078
>
>URL for this Security Advisory:
>http://www.openssl.org/news/secadv_20030219.txt
>______________________________________________________________________
>OpenSSL Project                                 http://www.openssl.org
>Announcement Mailing List                 openssl-announce at openssl.org
>Automated List Manager                           majordomo at openssl.org




More information about the ag-dev mailing list