The 6.6.7.rc2 release candidate is available (security fix for NTLM reassessed to be DoS only)
Matthias Andree via Fetchmail-users <[email protected]> Fri, 24 Jul 2026 01:54:02 +0200
| Newsgroups | gmane.mail.fetchmail.user |
|---|---|
| Message-ID | <amKpmhbnuSTMyFLh__42328.3071884484$1784850878$gmane$org@ryzen.an3e.de> |
--===============8673567455007545908== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dXyVncKr0RH/FbYf" Content-Disposition: inline --dXyVncKr0RH/FbYf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The 6.6.7.rc2 release of fetchmail is now available at the usual locations, including <https://downloads.sourceforge.net/project/fetchmail/branch_6.6/>. The severity of the NTLM stack buffer overflow has been reassessed and it is believed that this cannot be used to change fetchmail's=20 control flow, but a denial of service was possible in case compiler hardenings, such as stack or memory protectors, cause fetchmail to be terminated. The source archive is available at: <https://downloads.sourceforge.net/project/fetchmail/branch_6.6/fetchmail-6= =2E6.7.rc2.tar.xz/download> The detached GnuPG signature is available at: <https://downloads.sourceforge.net/project/fetchmail/branch_6.6/fetchmail-6= =2E6.7.rc2.tar.xz.asc/download> The SHA256 hashes for the tarballs are: SHA2-256(fetchmail-6.6.7.rc2.tar.xz)=3D 223e2e7c32ed8825900043a5bcdf93b8155= d81b5d05ee21e8b993fce59556c8d Here are the release notes: ---------------------------------------------------------------------------= ----- fetchmail-6.6.7 (not yet released): ## BUGFIXES: * Safeguard internal NTLM buffer handling to avoid overrun if server sends extremely long fields in the challenge, to avoid stack corruption. Reported by "Tristan". The code will report the buffer sizing issue and abort the NTLM authentic= ation flow properly so that it's clear that message sizes are the issue. Fetchmail 6.6.7 currently supports 1 kByte of NTLM payload for each of the three messages, plus header. Earlier reports of this bug overestimated the impact. While the bug indeed can write beyond the end of a stack-based buffer, it is reaching into another stack-based buffer that is at least 2048 bytes large, whereas the overflow is a few dozen bytes at most. The worst impact is that the NegotiateFlags value in the final Authenticate Message step of the NTLM authentication protocol gets messed up and the authentication fails. It MAY happen, depending on hardening, stack protection and other compiler flags that these protections terminate fetchmail because one write to a data structure crosses into an other variable that is adjacent, on normal stack layouts that "victim" would be the challenge message. NOTE: NTLM is based on obsolete cryptographic mechanisms and should not be used without TLS or SSL security for the transport. NOTE: fetchmail 7 will remove support for NTLM and MSN authentication. Microsoft (who own the specification) generally advises that applications should not use NTLM, and is replacing with with Kerberos, see [MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol, https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/ See Introduction and Security Considerations for Implements (In Version 37.0 of the spec, sections 1 and 5.1 on page 84) Since this WAS initially reported as a stack smashing vulnerability, a security announcement fetchmail-SA-2026-01 will be issued to reduce the severity of the impact in public reporting. * The IMAP protocol exchange was made stricter, (1) it will validate tagged responses that we received the right response to make sure fetchmail and the IMAP server are still in synch, (2) it will no longer accept the response words OK, NO, BAD, BYE if there is trailing garbage, and will now reject "OKAY" or "NONE", which would previously be accepted as aliases for OK or NO. * For NTLM: Made protocol exchange more robust and make it track errors and SASL cancellation better to avoid hangs if NTLM does not work but oth= er authentication schemes do or NTLM gets rejected by the server. * Handling of escape sequences in the rcfile has been bugfixed to handle all ISO C escape sequences and handle octal escapes more strictly. ---------------------------------------------------------------------------= ---- These parts are from the .rc1 announcement about the NTLM: Workaround: use the --auth PARAM option, where PARAM is another mechanism (not NTLM) supported by fetchmail and by the IMAP or POP3=20 server. This may not be viable on shared multi-user systems. Workaround for distributors and system operators: Recompile fetchmail with --disable-NTLM option and reinstall it. To confirm, look at the fetchmail -V | head -1 output, it should NOT=20 mention +NTLM. The immediate minimal fix can be cherry-picked from https://gitlab.com/fetchmail/fetchmail/-/commit/cb5be5c38471eec19e519ace0bc= 569176317ea92 with a compiler warning fix in https://gitlab.com/fetchmail/fetchmail/-/commit/ddf19ffab973bf6a424f878faa8= ff6753ddf6246 --dXyVncKr0RH/FbYf Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE3EplW9mTzUhx+oIQ5BKxVu/zhVoFAmpiqZoACgkQ5BKxVu/z hVrAxhAAmDiezfNPJNB5W5MzVi9vO+JEC01lFw9z78YWakVBxsezmGp/0kJiDhnn 5Fusk7YxgyJds8fVz6X/ednwgelVuJC+4tQWCoOXMq2KyfW2q++BKVC+tdArJP3h GpnmlfImgOoyX9xgWvPjcXH4BFVUxwTeVF8voLeQgv6BDu4IUZwB97nMnRTxSHso ygddYwq2Tq1wb+VfPs1h8Uh3v+1CLJME76ZfvscxVFGsa6tff82+0mMBjyAXSQ+B qBNGZ6+yIXyvvI5u51jJH3P/829d5j8gR7xMkbzaOGB3phLYd1NRlkBEuu3c/SVp CZhjS5hHRqKkf7qoLVrmDWEO1dLnjrtt6P7w6sOy6MBvY6SRclMjkYTwC3XcGpOL ndLQi+niFJ44wUeBFaZ/VooV7dPV128zoeT2tAQftOon5To3FmCEA30/5ajob2GX 1ESnwsojNpOU1hF4bWBh6i/0dGqHDqdXgvIEfOW8PGeh3o5GOqm1yPvyDzKgDMCq sSb4MAfDCrT5RJk6sKrA+V+k0rChflbqgH6EbNxidCAwB+H3ACY690A9hvqYAN6Q QNdHG6om1iBsTRstSAiBpXqRvGNl2kxerY3PZ6ynVDi/am/ZJEO3zcqRbWNFTfjH ZmU56zMcA67l7ulN6gMGsPNoDe1AYVG1vujbkhfi2XEBz3Dl2nQ= =L0GH -----END PGP SIGNATURE----- --dXyVncKr0RH/FbYf-- --===============8673567455007545908== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============8673567455007545908== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Fetchmail-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fetchmail-users --===============8673567455007545908==--