This vulnerability caught my eye. I know of alot of people and underground groups that use Stunnel on there own servers to host more secure chat sessions etc..
Well just to inform you that there is a vulnerability with it. It says that the risk is high, but to be honest, as it says in the statement, the amount of connections that someone would need to make would not go un-noticed.
But it could be worth checking out for those of you who do use it.
Release Date: 2003-Mar-21
Versions: Stunnel 3.x x <= 22
Stunnel 4.x x <= 04
Problem type: Key discovery / Information Leakage
Exploit script: None publicly available
Discovery: D. Boneh, D. Brumley
Writeup: Brian Hatch <email@example.com
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.
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
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.
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.
* Recompile OpenSSL using the patch they have supplied and then recompile Stunnel.
* 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
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.
Date: 13 Mar 2003 16:09:17 -0800
From: David Brumley <firstname.lastname@example.org
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.