From: Matthias A. <mat...@gm...> - 2012-09-03 22:38:48
|
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> |