From: bri at ifokr.org (Brian Hatch)
Subject: Stunnel: RSA timing attacks / key discovery



Release Date:          2003-Mar-21
Package:               stunnel
Versions:              Stunnel 3.x    x <= 22
                       Stunnel 4.x    x <= 04
Problem type:          Key discovery / Information Leakage
Exploit script:        None publicly available
Severity:              High
Network-accessible:    yes
Network-accessible:    yes
Discovery:             D. Boneh, D. Brumley
Writeup:               Brian Hatch <bri@...nnel.org>

Summary:               SSL sessions where RSA blinding is not in effect
		       are vulnerable to timing attacks which could
		       allow a cracker to discover your private RSA key.

Description:
 
   Stunnel is an SSL wrapper able to act as an SSL client or server,
   enabling non-SSL aware applications and servers to utilize SSL encryption.

   Dan Boneh and David Brumley have successfully implemented an RSA
   timing attack against OpenSSL-enabled SSL software, including
   Stunnel.  Their writeup is available at
   http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html


Impact:
 
   If you use an RSA key for an SSL server, a determined cracker could
   eventually determine your key.  This could be used to impersonate
   your server via a man-in-the-middle attack, or to decrypt all SSL
   connections between client and server that can be sniffed/etc from
   the cracker's location.


Mitigating factors:

   The timing attack works best under situations where there is little
   or no network lag, such as over a localhost connection.  If the
   attacking host is more distant that network packets have a larger
   range of turnaround times may make the attack less successful.
   However a very slow CPU on the Stunnel server (which would process
   the RSA number crunching more slowly) may counteract the network lag.

   The number of connections an attacking host must make to discover
   the key is rather large, enough that you may well notice the increase
   in your CPU usage, number of available sockets, or volume of log
   messages spewing through your system.

Solution:
 
   * Recompile OpenSSL using the patch[1] they have supplied and then
     recompile Stunnel.

   or

   * Apply the patch for Stunnel 3.x available at 
     http://www.stunnel.org/patches/desc/blinding-3.x_bri.html

     or the patch for Stunnel 4.x available at 
     http://www.stunnel.org/patches/desc/blinding-4.x_bri.html

     and recompile Stunnel.


   I expect Stunnel 4.05 and 3.23 will be released which incorporate
   these or similar patches.
 

For more information about Stunnel, consult the folowing pages:

   http://stunnel.mirt.net/    # Official Stunnel home page
   http://www.stunnel.org/     # Stunnel.org: FAQ/Distribution/Patches/Etc


Discovery:

  The code to successfully perform an RSA timing attack against Stunnel
  was created by David Brumley and Dan Boneh.  Here is the original
  email they sent to the Stunnel mailing list on 13-Mar-2003.

  --------------------------------------------------------------------

  To: stunnel-users@...t.net
  Date: 13 Mar 2003 16:09:17 -0800
  From: David Brumley <dbrumley@...nford.edu>
  Subject: Timing attack against stunnel/OpenSSL
  
  Dan Boneh and I have been researching timing attacks against software
  crypto libraries.  Timing attacks are usually used to attack weak
  computing devices such as smartcards.  We've successfully developed and
  mounted timing attacks against software crypto libraries running on
  general purpose PC's.
  
  We found that we can recover an RSA secret from OpenSSL using anywhere
  from only 300,000 to 1.4 million queries.  We demonstrated our attack
  was pratical by successfully launching an attack against Apache +
  mod_SSL and stunnel on the local network.  Our results show that timing
  attacks are practical against widely-deploy servers running on the
  network.
  
  While OpenSSL definitely does provide for blinding, mod_SSL doesn't
  appear to use it. One reason is it appears difficult to enable blinding
  from the SSL API.
  
  This paper was submitted to Usenix security 03.  The link to the paper
  is here:
  http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html
  
  We notified CERT about a month ago re: this attack, so it's possible you
  heard about this from them already.
  
  flames > /dev/null.  Feel free to write with any questions.
  
  Cheers,
  -David Brumley


  --------------------------------------------------------------------


--
Brian Hatch                  Quantum Mechanics:
   Systems and                The dreams stuff
   Security Engineer          is made of.
www.hackinglinuxexposed.com

Every message PGP signed

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20030321/6880e427/attachment.bin

Powered by blists - more mailing lists