The 6.6.7.rc1 release candidate is available (security fix for NTLM protocol, possible RCE)

--===============7839961886228190432==
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="7hAnwjhR9938AayA"
Content-Disposition: inline


--7hAnwjhR9938AayA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

The 6.6.7.rc1 release candidate of fetchmail tightens code
around a security vulnerability in the NTLM code.
It is now available at the usual locations, including=20
<https://downloads.sourceforge.net/project/fetchmail/branch_6.6/>.

Depending on compilation options around --enable-NTLM and protective=20
features such as stack smashing protection, fortification and other=20
means, around 52 bytes might be overwritten on the stack, and we
cannot rule out that remote code execution be mounted.

Fetchmail builds that did not enable NTLM at compile time are=20
unaffected.  fetchmail -V | head -1 will show "+NTLM" if NTLM was=20
enabled, for instance (note the presence of +NTLM):

This is fetchmail release 6.6.2+GSS+RPA+NTLM+SDPS+TLS+NLS+KRB5.

A version in French locale that is not vulnerable to this NTLM
bug might reporto (note the absense of +NTLM):
Ceci est fetchmail, version 6.6.7.rc1+TLS+NLS.


The security announcement will be provided at a later date, it is
important to get the fix out; inaccuracies in the report might hint
at AI being used in the generation of the report, so holding back=20
anything whilst a simple fix is available is a disservice to users.

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

Note though that 6.6.7.rc1's NTLM authentication fixed other bugs that=20
are believed to not be exploitable beyond slowing down fetchmail while=20
waiting for server I/O, which usually would not be a high risk.
Fetchmail usually applies timeouts to network reads.

The .pot file has been provided to the translation project, we have=20
a few new messages that need translation.

Please report any regressions to the fetchmail-user mailing list,
or if security-sensitive observations are made, directly to me.


Note on AI assisted bugfinding and -fixing:
* Tell your AI to reply tersely and any assurances that are not
verifiably proven and that you have not proved to be true.
Some AIs guess and then are very assertive, like a lying child,
that it really is what it is, but does not provide the proof.
I am not interested in reading such AI slop. That time is
wasted and not available for other development work.
* Provide a proof of concept, or a unit test or similar, as code,
and prove that it practically compiles on a recent release version of=20
Fedora Linux, FreeBSD, OpenBSD or Debian Linux.  I won't follow manual=20
instructions.  It must compile out of the box within the folder of the
latest release package of fetchmail or build directory.
* Be careful with what AIs believe to be root causes or suggest as=20
fixes.  Before providing an AI fix suggestion, prove that it fixes
not only one particular situation, but apply experience-based testing
or fuzzing to prove similar situations are also implied in the fix.


The source archive is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.6/fetchmail-6=
=2E6.7.rc1.tar.xz/download>

The detached GnuPG signature is available at:
<https://downloads.sourceforge.net/project/fetchmail/branch_6.6/fetchmail-6=
=2E6.7.rc1.tar.xz.asc/download>

The SHA256 hashes for the tarballs are:
SHA2-256(fetchmail-6.6.7.rc1.tar.xz)=3D d03b9abee39c64333703dc1d2512f025969=
8a5e130d344c375e1b42d1d2056e4


Here are the release notes:
---------------------------------------------------------------------------=
-----
fetchmail-6.6.7 (not yet released):

## SECURITY BUGFIX FOR --enable-NTLM builds:
* 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.

  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)

## BUGFIXES:
* 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,
  such as OKAY or NONE.
* 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.

---------------------------------------------------------------------------=
----
fetchmail-6.6.6 (released 2026-06-24, 32443 LoC):

## CRITICAL BUGFIX FOR IMAP:
* The IMAP client, which has always used message indexes for the selected
  mailbox, did not abort when receiving an EXPUNGE response - which changes
  message numbers inside the mailbox.  Unlike UIDs, the message numbers are
  not stable and fetchmail does not have internal interfaces to track which
  messages are deleted, and adding those to a 6.6.X release would be too
  risky, and switching to UID is also too big a change, so we have no
  choice but to abort the session when seeing an EXPUNGE response without
  our own EXPUNGE request, to avoid marking the wrong message as seen/delet=
ed
  or skip the wrong one, or assume the wrong message size.
  Earl Chew reported this versus Yahoo Mail via Gitlab Work Item #91, which
  automatically expunges messages that are marked with the \Deleted flag.

  This has one new message for which we do not have translations yet,
  it is urgent to get the fix in the field.

---------------------------------------------------------------------------=
----

--7hAnwjhR9938AayA
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3EplW9mTzUhx+oIQ5BKxVu/zhVoFAmo/ymMACgkQ5BKxVu/z
hVpoLg/+NnlFWr2QiBi0FwOnOQq7FnKl/IPZxNSQHG1OK3yQlv9B6fpxYrOGSNnU
xR0a6WqBI98dNEl1B2rmOx4vQ2IixJ5RthsZinehSUTEmG4b3vPhScctjTjBV/Pz
/8vu+Q6bnydyBCoVdwertNBFobwKElB1JG5HEit5rXwJbWWZWmmP3epBq2EQRvtR
qpcZ7ocv60SvPlcEUETlKcRTxcV8C9kCDLJiiHj9XMHs1AsWD4f3p3yKtsw7fiTM
2sKRh0T8WcVgrg4YicZcUz1wDX+/QKRMWWQ7oocdD0ysFH3NZkvSHbLBvLa5I6At
UwcT0t0Fzm77LJAnKPHnla/ru2jPD0D6w4S7wwVD+y0obO/Htq7untpdqiKlkaYx
RapaefKV6LnbSDs6bUMYy4vYz+7/WV4zFFSSNxDIDhVrbLo9XfvWfA+c9YfLQXQz
eF/eNpGv6Yr0QDqG60Dzeocmy7xghSAAM3QXnZt8BQ7wctWgr5RmKiQZ1NqpPHuN
Np+tyzrsXWOVn9mTwn/R9kxI7WuE60tHwtMV6bcDIj5pdcAuZQtQMot/AEk9BnhZ
5XUBpsiEAuZn3RCHkj4yt9ak+dyIS7knm9eCoPOGBVJftVLnUqOpZZg/MXq+OyPC
EdGLM2TsSykYm1oqTKMA8H2IQx7M3bYUUmDKzX7wzIzvq6pTssc=
=INry
-----END PGP SIGNATURE-----

--7hAnwjhR9938AayA--


--===============7839961886228190432==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============7839961886228190432==
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

--===============7839961886228190432==--