| Message ID | 20260913171230.3920551-14-adolf.belka@ipfire.org |
|---|---|
| State | New |
| Headers |
Return-Path: <development+bounces-2611-patchwork=ipfire.org@lists.ipfire.org> Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (Client CN "mail01.haj.ipfire.org", Issuer "YR2" (not verified)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4hjZbk1HyZz3xTW for <patchwork@web04.haj.ipfire.org>; Sun, 13 Sep 2026 17:12:50 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [IPv6:2001:678:b28::201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (Client CN "mail02.haj.ipfire.org", Issuer "YE1" (not verified)) by mail01.ipfire.org (Postfix) with ESMTPS id 4hjZbg10b1z8fJ for <patchwork@ipfire.org>; Sun, 13 Sep 2026 17:12:47 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4hjZbc10y9z37CB for <patchwork@ipfire.org>; Sun, 13 Sep 2026 17:12:44 +0000 (UTC) X-Original-To: development@lists.ipfire.org Received: from mail01.ipfire.org (mail01.haj.ipfire.org [IPv6:2001:678:b28::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (Client CN "mail01.haj.ipfire.org", Issuer "YR2" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4hjZbX3RVpz34GY for <development@lists.ipfire.org>; Sun, 13 Sep 2026 17:12:40 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4hjZbT5Glmz6VV; Sun, 13 Sep 2026 17:12:37 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1789319557; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MneNTtU86UK5S9rKq+zKBnbLXAAXIqAG5+5pI8cr9XU=; b=Hs1lSKi4vreApi3ebASHWsr5A7uEdKnJzO4de5RrTZzm8fECV5DxFHxXrcaoiIWMcJoHt4 C2j3GFodve2A/NAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1789319557; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MneNTtU86UK5S9rKq+zKBnbLXAAXIqAG5+5pI8cr9XU=; b=gkRR/uEEB6f8qwZjtM4zh0DZYz8hiL2O35i5g+rER3e4eFG/fz0zD2jyrpcPEonXubfm2w lXaUohwmxcatgCeJLWUF6CgvKXDS0927j9uPgtLY1MUP1ap78kPNqKG1jwSdBpsF51JBa6 /PLIS7VNfjlrmYTarLi7GewJUAWznkcU4DNZ2eoM1PE2FHA2UFj3308vcx196qkGIPLqwS mUBm/scqQvfcXLtJv6wE8GieSNlMAEqd2K1ZmSYqnwiCk++7P+bTXUUdL2QlvGrpeQiJSi 4/zD5IVmGHwoSidGmaSAGV4EiMDLh5qHA6kxjd+/4zOtvXHcJDX2hBejpdkh8A== From: Adolf Belka <adolf.belka@ipfire.org> To: development@lists.ipfire.org Cc: Adolf Belka <adolf.belka@ipfire.org> Subject: [PATCH] fetchmail: Update to version 6.6.7 Date: Sun, 13 Sep 2026 19:12:13 +0200 Message-ID: <20260913171230.3920551-14-adolf.belka@ipfire.org> In-Reply-To: <20260913171230.3920551-1-adolf.belka@ipfire.org> References: <20260913171230.3920551-1-adolf.belka@ipfire.org> Precedence: list List-Id: <development.lists.ipfire.org> List-Subscribe: <https://lists.ipfire.org/>, <mailto:development+subscribe@lists.ipfire.org?subject=subscribe> List-Unsubscribe: <https://lists.ipfire.org/>, <mailto:development+unsubscribe@lists.ipfire.org?subject=unsubscribe> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development+help@lists.ipfire.org?subject=help> Sender: <development@lists.ipfire.org> Mail-Followup-To: <development@lists.ipfire.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit |
| Series |
fetchmail: Update to version 6.6.7
|
|
Commit Message
Adolf Belka
13 Sep 2026, 5:12 p.m. UTC
- Update from version 6.6.6 to 6.6.7
- No change in rootfile
- Changelog
6.6.7
Fetchmail 6.6.7 is the eighth fetchmail 6.6 release, it fixes a NTLM stack buffer
overflow bug that can lead to remote code execution if NTLM is enabled at configure
time. There has been some confusion as to the exploitability, but because the C
standard does not guarantee a particular layout of stack variables, the security
announcement fetchmail-SA-2006-01.txt is being re-issued. The NEWS file in the 6.6.7
release (contents used for changelog below) claims the release were non-vulnerable,
which is no longer believed to be correct, and NTLM-enabled fetchmail 6.6.6 and
older must be considered vulnerable. This version fixes various other NTLM
authenticator protocol bugs, makes IMAP protocol exchange a bit stricter to avoid
desynch, and fixes build issues of the test suite on Cygwin's updated GCC 14.
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 authentication
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 COULD previously happen, depending on hardening, stack protection and
other compiler flags that these _protections_ terminated 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, which was already read except for its "flags" value. The
termination can happen, for instance, with the Address Sanitizer feature,
or other features that separate variables into pages of their own or
put "canary"/sentinel values between them in the memory layout.
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 (which owns 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 has been 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 other
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.
* The AC_LIBOBJ extensions have been moved to a lib/ subdirectory
in an attempt to fix build issues on Cygwin, see #96 reported by Achim.
TRANSLATION UPDATES were contributed by these fine people - thank you!
* eo: Keith Bowes [Esperanto]
* ja: Takeshi Hamasaki [Japanese]
* ro: Remus-Gabriel Chelu [Romanian]
* cs: Petr Pisar [Czech]
* es: Cristian Othón Martínez Vera [Spanish]
* sv: Göran Uddeborg [Swedish]
* fr: Frédéric Marchal [French]
* pl: Jakub Bogusz [Polish]
* it: Luca Vercelli [Italian]
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
---
lfs/fetchmail | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lfs/fetchmail b/lfs/fetchmail index 4b5fc42d7..6d9c4c2d5 100644 --- a/lfs/fetchmail +++ b/lfs/fetchmail @@ -26,7 +26,7 @@ include Config SUMMARY = Full-Featured POP and IMAP Mail Retrieval Daemon -VER = 6.6.6 +VER = 6.6.7 THISAPP = fetchmail-$(VER) DL_FILE = $(THISAPP).tar.xz @@ -34,7 +34,7 @@ DL_FROM = $(URL_IPFIRE) DIR_APP = $(DIR_SRC)/$(THISAPP) TARGET = $(DIR_INFO)/$(THISAPP) PROG = fetchmail -PAK_VER = 26 +PAK_VER = 27 DEPS = @@ -48,7 +48,7 @@ objects = $(DL_FILE) $(DL_FILE) = $(DL_FROM)/$(DL_FILE) -$(DL_FILE)_BLAKE2 = 0f7a26a2f34d902d30801d5016e67697877f7c3f41dc9d9c4a1b44420c9e08f6acd94853c298b2938b9ddf08b3aa3115a14917f42d680f3ada8daba0e5f50953 +$(DL_FILE)_BLAKE2 = 5c0a974b67e4c3392ab4de2b14eb5e34a0bff8eac48d2a5f412bfb500333df601e563d41dc26b897534a705c253222d13eb16e23dbefd0f82e945ae94cbf66ba install : $(TARGET)