ANNOUNCE: fetchmail 6.4.22 release candidate available (security and crash fixes)

Matthias Andree <[email protected]> Fri, 27 Aug 2021 20:02:21 +0200

Newsgroups	gmane.mail.fetchmail.user
Message-ID	<YSkorcUipXwh+QDQ__41152.5879333325$1630087387$gmane$org@ryzen.an3e.de>

Greetings,

The 6.4.22 release CANDIDATE #2 of fetchmail is now available at
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/>.

It contains security fixes for CVE-2021-39272 and fixes up several protocol
violations along the way, fixes some configuration-based crashes (SIGSEGV) and
updates the documentation.

This version has quite extensive changes for a patchlevel release.

rc2 fixes an IMAP protocol regression of rc1 that made it unable to
download e-mail via IMAP in many circumstances.

Note that security recommendations in README.SSL were changed to achieve higher
security from the configuration. Built-in defaults do not change.

Please test this thoroughly and report your findings so we can be sure that
6.4.22 will be a good release. It has been mailed out to the translation
project to solicit translation updates.

The source archive is available at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.22.rc2.tar.xz/download>

Detached GnuPG signatures for the respective tarballs are at:
<https://sourceforge.net/projects/fetchmail/files/branch_6.4/fetchmail-6.4.22.rc2.tar.xz.asc/download>

SHA256 hash values for the tarballs:
SHA256(fetchmail-6.4.22.rc2.tar.xz)= 1bd3f25e221ea01de4ba57447b7464f8c5f07f0f107701583b9cdd85740da276

Here are the release notes:

---------------------------------------------------------------------------------
fetchmail-6.4.22 (not yet released):

# SECURITY FIXES:
* On IMAP connections, without --ssl and with nonempty --sslproto, meaning that
fetchmail is to enforce TLS, and when the server or an attacker sends
a PREAUTH greeting, fetchmail used to continue an unencrypted connection.
Now, log the error and abort the connection.
Recommendation for servers that support SSL/TLS-wrapped or "implicit" mode on
a dedicated port (default 993): use --ssl, or the ssl user option in an rcfile.
Reported by: Andrew C. Aitchison, based on the USENIX Security 21 paper "Why
TLS is better without STARTTLS - A Security Analysis of STARTTLS in the Email
Context" by Damian Poddebniak, Fabian Ising, Hanno Böck, and Sebastian
Schinzel. The paper did not mention fetchmail.
* On IMAP and POP3 connections, --auth ssh no longer prevents STARTTLS
negotiation.
* On IMAP connections, fetchmail does not permit overriding a server-side
LOGINDISABLED with --auth password any more.
* On POP3 connections, the possibility for RPA authentication (by probing with
an AUTH command without arguments) no longer prevents STARTTLS negotiation.
* For POP3 connections, only attempt RPA if the authentication type is "any".

# BUG FIXES:
* On IMAP connections, when AUTHENTICATE EXTERNAL fails and we have received the
tagged (= final) response, do not send "*".
* On IMAP connections, AUTHENTICATE EXTERNAL without username will properly send
a "=" for protocol compliance.
* On IMAP connections, AUTHENTICATE EXTERNAL will now check if the server
advertised SASL-IR (RFC-4959) support and otherwise refuse (fetchmail <= 6.4
has not supported and does not support the separate challenge/response with
command continuation)
* On IMAP connections, when --auth external is requested but not advertised by
the server, log a proper error message.
* Fetchmail no longer crashes when attempting a connection with --plugin "" or
--plugout "".
* Fetchmail no longer leaks memory when processing the arguments of --plugin or
--plugout on connections.
* On POP3 connections, the CAPAbilities parser is now caseblind.
* Fix segfault on configurations with "defaults ... no envelope". Reported by
Bjørn Mork. Fixes Debian Bug#992400. This is a regression in fetchmail 6.4.3
and happened when plugging memory leaks, which did not account for that the
envelope parameter is special when set as "no envelope". The segfault happens
in a constant strlen(-1), triggered by trusted local input => no vulnerability.

# CHANGES:
* IMAP: When fetchmail is in not-authenticated state and the server volunteers
CAPABILITY information, use it and do not re-probe. (After STARTTLS, fetchmail
must and will re-probe explicitly.)
* For typical POP3/IMAP ports 110, 143, 993, 995, if port and --ssl option
do not match, emit a warning and continue. Closes Gitlab #31.
(cherry-picked from 6.5 beta branch "legacy_6x")
* fetchmail.man and README.SSL were updated in line with RFC-8314/8996/8997
recommendations to prefer Implicit TLS (--ssl/ssl) and TLS v1.2 or newer,
placing --sslproto tls1.2+ more prominently.
The defaults shall not change between 6.4.X releases for compatibility.

# TRANSLATIONS: These language translations were updated by these fine people:
* fr: Frédéric Marchal [French]
* eo: Keith Bowes [Esperanto]

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

Happy fetches,
Matthias

_______________________________________________
Fetchmail-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fetchmail-users

signature.asc (application/pgp-signature, 833 B)