fetchmail-devel

[fetchmail-devel] PATCH: Clear SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS without SSL_CTX_clear_options()

[Earl C. <ear...@ya...>]

A patch to clear SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS was added recently:

  http://gitorious.org/fetchmail/fetchmail/commit/48809c5b9f6c9081f4031fa938dd63b060c18a4b?format=patch

Older implementations of OpenSSL do not support SSL_CTX_clear_options().



This patch reworks the previous change to avoid the use of SL_CTX_clear_options()
and instead clears the corresponding bit in SSL_OP_ALL before calling
SSL_CTX_set_options().



--- socket.c.orig       2012-08-13 13:02:41.000000000 -0700
+++ socket.c    2012-09-03 08:11:49.000000000 -0700
@@ -844,6 +844,7 @@
 {
         struct stat randstat;
         int i;
+        long sslopts = SSL_OP_ALL;

        SSL_load_error_strings();
        SSL_library_init();
@@ -899,14 +900,14 @@
                return(-1);
        }

-       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);
+               sslopts &= ~ SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS;
        }

+       SSL_CTX_set_options(_ctx[sock], sslopts);
+
        if (certck) {
                SSL_CTX_set_verify(_ctx[sock], SSL_VERIFY_PEER, SSL_ck_verify_callback);
        } else {

Re: [fetchmail-devel] PATCH: Clear SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS without SSL_CTX_clear_options()

[Matthias A. <mat...@gm...>]

Am 03.09.2012 17:24, schrieb Earl Chew:
> 
> 
> A patch to clear SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS was added recently:
> 
>   http://gitorious.org/fetchmail/fetchmail/commit/48809c5b9f6c9081f4031fa938dd63b060c18a4b?format=patch
> 
> Older implementations of OpenSSL do not support SSL_CTX_clear_options().

Earl,

Thanks a lot for the problem report and the patch.

The question I am asking myself is: What use is there in supporting
"older implementations" (meaning before 0.9.8m)?  How many systems are
affected (and I would tend to ignore enterprise distributions - they
ought to patch OpenSSL instead).  I suppose those older implementations
would likely also be vulnerable to several other attacks, which might
subvert the effort of closing this (minor) hole.

Any insights?

Best regards,
Matthias

Re: [fetchmail-devel] PATCH: Clear SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS without SSL_CTX_clear_options()

[Earl C. <ear...@ya...>]

Matthias,

> The question I am asking myself is: What use is there in supporting
> "older implementations" (meaning before 0.9.8m)?  How many systems are
> affected (and I would tend to ignore enterprise distributions - they
> ought to patch OpenSSL instead).  I suppose those older implementations
> would likely also be vulnerable to several other attacks, which might
> subvert the effort of closing this (minor) hole.

Yes, a reasonable question to ask.

I think that there are two separate considerations:

a. The absence/presence of SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS
b. The absence/presence of SSL_CTX_clear_options()


My reading is that (a) is the key to closing the vulnerability. The availability of SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS
indicates that the vulnerability is closed and it is important that SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS
is _not_ set in this scenario (except when overridden by FETCHMAIL_DISABLE_CBC_IV_COUNTERMEASURE).

There are two obvious ways to achieve this. One way is to simply clear the bit in SSL_OP_ALL,
and for prior art, I refer you to:


http://www.opensource.apple.com/source/curl/curl-69.1/patches/curl-dont-insert-empty-fragments.patch


This brings me to (b) which use SSL_CTX_clear_options() as an alternate way to manipulate the options. But as
the prior art shows, it is entirely unnecessary in this scenario to use this new function.



> I suppose those older implementations
> would likely also be vulnerable to several other attacks, which might
> subvert the effort of closing this (minor) hole.


As I described above, the whole question of using SSL_CTX_clear_options() is a separate
one from the ability to close down the vulnerability.

The patch I submitted keeps the vulnerability closed, but does not require SSL_CTX_clear_options().

As you have probably figured out, one of the OpenSSL installations that I have (1.0.0-0.10.beta3.fc12) supports
SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS but does not support SSL_CTX_clear_options().


Earl

Re: [fetchmail-devel] PATCH: Clear SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS without SSL_CTX_clear_options()

[Matthias A. <mat...@gm...>]

Am 03.09.2012 21:43, schrieb Earl Chew:
> Matthias,
> 
>> The question I am asking myself is: What use is there in supporting
>> "older implementations" (meaning before 0.9.8m)?  How many systems are
>> affected (and I would tend to ignore enterprise distributions - they
>> ought to patch OpenSSL instead).  I suppose those older implementations
>> would likely also be vulnerable to several other attacks, which might
>> subvert the effort of closing this (minor) hole.
> 
> Yes, a reasonable question to ask.
> 
> I think that there are two separate considerations:
> 
> a. The absence/presence of SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS
> b. The absence/presence of SSL_CTX_clear_options()
> 
> 
> My reading is that (a) is the key to closing the vulnerability. The availability of SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS
> indicates that the vulnerability is closed and it is important that SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS
> is _not_ set in this scenario (except when overridden by FETCHMAIL_DISABLE_CBC_IV_COUNTERMEASURE).

Earl,

we agree on the assessment of how to close the vulnerability, and on
ways to leave the flag unset, assuming that OpenSSL defaults to "off"
(which it does for official 0.9.8 and 1.0.0 releases, and probably
future releases).

The SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS feature dates back to 2002, so we
can check that list item off.

Perhaps I can reword my question on how wide-spread the issue is a
little bit: are there open-source distributions that are still supported
by their "vendor" where this is a real-world problem, rather than just
continued use of an unsupported version?

> The patch I submitted keeps the vulnerability closed, but does not require SSL_CTX_clear_options().

That we also agree on - providing that nobody hacked the SSL defaults.

> As you have probably figured out, one of the OpenSSL installations that I have (1.0.0-0.10.beta3.fc12) supports
> SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS but does not support SSL_CTX_clear_options().

The "0.10.beta3" and "fc12" labels reveal that your package is from a
distribution (Fedora 12 "Constantine") that went unsupported almost two
years ago (*), and as such is not supported by fetchmail either.

Fedora 12 was using a pre-1.0.0 beta release of OpenSSL, and went out of
support before OpenSSL 1.0.0 got released.

I will queue your patch in Git now that it is there and that it fixes a
regression, but whether there will be a fetchmail 6.3.23 release is open.

(*)
<https://lists.fedoraproject.org/pipermail/announce/2010-December/002895.html>

Re: [fetchmail-devel] PATCH: Clear SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS without SSL_CTX_clear_options()

[Earl C. <ear...@ya...>]

Matthias,

> I will queue your patch in Git now that it is there and that it fixes a regression, but whether there will
> be a fetchmail 6.3.23 release is open.
Yes, thanks. I understand.

Earl