Compare commits

...

No commits in common. "c8s" and "c8-beta" have entirely different histories.
c8s ... c8-beta

4 changed files with 139 additions and 1 deletions

View File

@ -0,0 +1,41 @@
From 29754579de3a4e720ea0b30bc3e4c03dd905fd66 Mon Sep 17 00:00:00 2001
From: Kevin McCarthy <kevin@8t8.us>
Date: Sun, 3 Sep 2023 12:22:01 +0800
Subject: [PATCH] Fix rfc2047 base64 decoding to abort on illegal characters.
For some reason, the rfc2047 base64 decoder ignored illegal
characters, instead of aborting. This seems innocuous, but in fact
leads to at least three crash-bugs elsewhere in Mutt.
These stem from Mutt, in some cases, passing an entire header
field (name, colon, and body) to the rfc2047 decoder. (It is
technically incorrect to do so, by the way, but is beyond scope for
these fixes in stable). Mutt then assumes the result can't be empty
because of a previous check that the header contains at least a colon.
This commit takes care of the source of the crashes, by aborting the
rfc2047 decode. The following two commits add protective fixes to the
specific crash points.
Thanks to Chenyuan Mi (@morningbread) for discovering the strchr
crashes, giving a working example draft message, and providing the
stack traces for the two NULL derefences.
(cherry picked from commit 452ee330e094bfc7c9a68555e5152b1826534555)
---
rfc2047.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rfc2047.c b/rfc2047.c
index 488771bd..1a765b87 100644
--- a/rfc2047.c
+++ b/rfc2047.c
@@ -716,7 +716,7 @@ static int rfc2047_decode_word (BUFFER *d, const char *s, char **charset)
if (*pp == '=')
break;
if ((*pp & ~127) || (c = base64val(*pp)) == -1)
- continue;
+ goto error_out_0;
if (k + 6 >= 8)
{
k -= 2;

View File

@ -0,0 +1,37 @@
From 427e205f3f5759c153a1d424ac6f6a82ac16a352 Mon Sep 17 00:00:00 2001
From: Kevin McCarthy <kevin@8t8.us>
Date: Sun, 3 Sep 2023 14:11:48 +0800
Subject: [PATCH] (CVE-2023-4874) Fix write_one_header() illegal header check.
This is another crash caused by the rfc2047 decoding bug fixed in the
second prior commit.
In this case, an empty header line followed by a header line starting
with ":", would result in t==end.
The mutt_substrdup() further below would go very badly at that point,
with t >= end+1. This could result in either a memcpy onto NULL or a
huge malloc call.
Thanks to Chenyuan Mi (@morningbread) for giving a working example
draft message of the rfc2047 decoding flaw. This allowed me, with
further testing, to discover this additional crash bug.
(cherry picked from commit a4752eb0ae0a521eec02e59e51ae5daedf74fda0)
---
sendlib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sendlib.c b/sendlib.c
index 8fd5e6cb..8569e5cf 100644
--- a/sendlib.c
+++ b/sendlib.c
@@ -2038,7 +2038,7 @@ static int write_one_header (FILE *fp, int pfxw, int max, int wraplen,
else
{
t = strchr (start, ':');
- if (!t || t > end)
+ if (!t || t >= end)
{
dprint (1, (debugfile, "mwoh: warning: header not in "
"'key: value' format!\n"));

View File

@ -0,0 +1,47 @@
From 74b4833b56212dbbac6f6353f6989f91176671a2 Mon Sep 17 00:00:00 2001
From: Kevin McCarthy <kevin@8t8.us>
Date: Mon, 4 Sep 2023 12:50:07 +0800
Subject: [PATCH] (CVE-2023-4875) Check for NULL userhdrs.
When composing an email, miscellaneous extra headers are stored in a
userhdrs list. Mutt first checks to ensure each header contains at
least a colon character, passes the entire userhdr field (name, colon,
and body) to the rfc2047 decoder, and safe_strdup()'s the result on
the userhdrs list. An empty result would from the decode would result
in a NULL headers being added to list.
The previous commit removed the possibility of the decoded header
field being empty, but it's prudent to add a check to the strchr
calls, in case there is another unexpected bug resulting in one.
Thanks to Chenyuan Mi (@morningbread) for discovering the two strchr
crashes, giving a working example draft message, and providing the
stack traces for the two NULL derefences.
(cherry picked from commit 4cc3128abdf52c615911589394a03271fddeefc6)
---
sendlib.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sendlib.c b/sendlib.c
index 8569e5cf..007baac1 100644
--- a/sendlib.c
+++ b/sendlib.c
@@ -2318,7 +2318,7 @@ int mutt_write_rfc822_header (FILE *fp, ENVELOPE *env, BODY *attach, char *date,
/* Add any user defined headers */
for (; tmp; tmp = tmp->next)
{
- if ((p = strchr (tmp->data, ':')))
+ if ((p = strchr (NONULL (tmp->data), ':')))
{
q = p;
@@ -2366,7 +2366,7 @@ static void encode_headers (LIST *h)
for (; h; h = h->next)
{
- if (!(p = strchr (h->data, ':')))
+ if (!(p = strchr (NONULL (h->data), ':')))
continue;
i = p - h->data;

View File

@ -20,7 +20,7 @@
Summary: A text mode mail user agent
Name: mutt
Version: 2.0.7
Release: 2%{?dist}
Release: 3%{?dist}
Epoch: 5
# The entire source code is GPLv2+ except
# pgpewrap.c setenv.c sha1.c wcwidth.c which are Public Domain
@ -42,6 +42,11 @@ Patch12: mutt-1.9.5-nodotlock.patch
Patch13: mutt_disable_ssl_enforce.patch
Patch14: mutt-2.0.7-cve-2022-1328.patch
# CVE-2023-4874 CVE-2023-4875
Patch0015: 0015-Fix-rfc2047-base64-decoding-to-abort-on-illegal-char.patch
Patch0016: 0016-CVE-2023-4874-Fix-write_one_header-illegal-header-ch.patch
Patch0017: 0017-CVE-2023-4875-Check-for-NULL-userhdrs.patch
# Coverity patches
# https://cov01.lab.eng.brq.redhat.com/el8-results/el8/mutt-1.9.3-1.el8+7/scan-results-imp.html
Patch111: mutt-1.10.1-mutt-1.9.3-1_coverity_166.patch
@ -104,6 +109,10 @@ autoreconf --install
%patch13 -p1
%patch14 -p1 -b .cve-2022-1328
%patch15 -p1
%patch16 -p1
%patch17 -p1
%patch111 -p1 -b .mutt-1.9.3-1_coverity_166
%patch112 -p1 -b .mutt-1.9.3-1_coverity_181
%patch113 -p1 -b .mutt-1.9.3-1_coverity_187_188_189_190.patch
@ -227,6 +236,10 @@ ln -sf ./muttrc.5 %{buildroot}%{_mandir}/man5/muttrc.local.5
%changelog
* Wed Oct 11 2023 Matej Mužila <mmuzila@redhat.com> - 5:2.0.7-3
- Fix for: CVE-2023-4874 CVE-2023-4875
- Resolves: RHEL-2811
* Thu Jul 21 2022 Matej Mužila <mmuzila@redhat.com> - 5:2.0.7-2
- Fix CVE-2022-1328 (#2109247)