Fix CVE-2011-3389 by clearing SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS...

...from SSL options, unless FETCHMAIL_DISABLE_CBC_IV_COUNTERMEASURE
is a non-empty environment variable.

Suggested by Apple.

diff --git a/NEWS b/NEWS
index 828fcb531e9184f09b674a350ebd6ae60a4e0028..1e297d6f19ce6469638a8a1802152e0fbf423b96 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -56,6 +56,28 @@ removed from a 6.4.0 or newer release.)
 
 --------------------------------------------------------------------------------
 
+fetchmail-6.3.22 (not yet released):
+
+# SECURITY FIX
+* CVE-2011-3389:
+  SSL/TLS (wrapped and STARTTLS): fetchmail used to disable a countermeasure 
+  against a certain kind of attack against cipher block chaining initialization 
+  vectors (SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS).
+  Whether this creates an exploitable situation, depends on the server and the 
+  negotiated ciphers.
+  As a precaution, fetchmail 6.3.22 enables the countermeasure, by clearing 
+  SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS.
+
+  NOTE that this can cause connections to certain non-conforming servers to 
+  fail, in which case you can set the environment variable 
+  FETCHMAIL_DISABLE_CBC_IV_COUNTERMEASURE to any non-empty value when starting
+  fetchmail to re-instate the compatibility option at the expense of security.
+
+  Reported by Apple Product Security.
+
+  For technical details, refer to <http://www.openssl.org/~bodo/tls-cbc.txt>.
+  See fetchmail-SA-2012-01.txt for further details.
+
 # BUG FIX
 * The Server certificate: message in verbose mode now appears on stdout like the
   remainder of the output. Reported by Henry Jensen, to fix Debian Bug #639807.
@@ -63,9 +85,10 @@ removed from a 6.4.0 or newer release.)
 # CHANGE
 * On systems where SSLv2_client_method isn't defined in OpenSSL (such as
   newer Debian, and Ubuntu starting with 11.10 oneiric ocelot), don't
-  reference it (to fix the build) and print a run-time error that the OS
-  does not support SSLv2. Fixes Debian Bug #622054, but note that that bug
-  report has a more thorough patch that does away with SSLv2 altogether.
+  reference it (to fix the build) and if configured, print a run-time error 
+  that the OS does not support SSLv2. Fixes Debian Bug #622054, 
+  but note that that bug report has a more thorough patch that does away with
+  SSLv2 altogether.
 
 # WORKAROUND
 * Some servers, notably Zimbra, return A1234 987 FETCH () in response to

diff --git a/fetchmail.man b/fetchmail.man
index e953a5dd0b5d6d68644a1a347247f0452ee4ae9a..974f5eacf3fbe243a6a69b175a62afed20bbfcbf 100644 (file)
--- a/fetchmail.man
+++ b/fetchmail.man
@@ -2781,6 +2781,16 @@ then that name is used as the default local name.  Otherwise
 session ID (this elaborate logic is designed to handle the case of
 multiple names per userid gracefully).
 
+.IP \fBFETCHMAIL_DISABLE_CBC_IV_COUNTERMEASURE\fP
+(since v6.3.22):
+If this environment variable is set and not empty, fetchmail will disable
+a countermeasure against an SSL CBC IV attack (by setting 
+SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS).  This is a security risk, but may be
+necessary for connecting to certain non-standards-conforming servers.
+See fetchmail's NEWS file and fetchmail-SA-2012-01.txt for details.
+Earlier fetchmail versions (v6.3.21 and older) used to disable this 
+countermeasure, but v6.3.22 no longer does that as a safety precaution.
+
 .IP \fBFETCHMAIL_INCLUDE_DEFAULT_X509_CA_CERTS\fP
 (since v6.3.17):
 If this environment variable is set and not empty, fetchmail will always load

diff --git a/socket.c b/socket.c
index 260b0aa31f16eaf5f0d9023716a57834ff024983..5f168b5b463e8aa88c93aaef0174cc7fdf6ea9c9 100644 (file)
--- a/socket.c
+++ b/socket.c
@@ -901,6 +901,12 @@ int SSLOpen(int sock, char *mycert, char *mykey, const char *myproto, int certck
 
        SSL_CTX_set_options(_ctx[sock], SSL_OP_ALL);
 
+       {
+           char *tmp = getenv("FETCHMAIL_DISABLE_CBC_IV_COUNTERMEASURE");
+           if (tmp == NULL || *tmp == '\0' || strspn(tmp, " \t") == strlen(tmp))
+               SSL_CTX_clear_options(_ctx[sock], SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS);
+       }
+
        if (certck) {
                SSL_CTX_set_verify(_ctx[sock], SSL_VERIFY_PEER, SSL_ck_verify_callback);
        } else {