Fix for CVE-2020-28007 causes build failure when DMARC is enabled
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
exim4 (Ubuntu) |
Fix Released
|
Low
|
Unassigned | ||
Bionic |
Won't Fix
|
Low
|
Bryce Harrington | ||
Focal |
Fix Released
|
Low
|
Unassigned | ||
Hirsute |
Fix Released
|
Low
|
Unassigned |
Bug Description
[Impact]
This is a regression in bionic's exim4 caused by the introduction of a CVE fix last year. It prevents users from accessing custom functionality from the shipped package when reconfiguring/
[Test Case]
To reproduce the build failure on bionic:
1. Save this file to Local/Makefile, to enable building dmarc.c
https:/
2. cp exim_monitor/EDITME Local/eximon.conf
3. sudo apt-get install -y exim4 libopendmarc-dev libspf2-dev
4. sudo apt-get build-dep -y exim4
5. make
(It should build successfully at this point since patches aren't applied)
6. quilt push -a
make
This should fail.
[Where problems could occur]
This change modifies a CVE patch, so the obvious concern would be if this invalidates the CVE. Mitigating this concern is that the change itself was suggested by a Ubuntu server team member, and that the change is isolated to code that is not even compiled for the stock package provided by bionic.
Since this affects code we don't compile, if the fix is incorrect for some reason, our regular CI won't detect it. So bugs related to custom compilation of bionic's exim4 could potentially be worth watching for.
[Original Report]
./debian/
Backport of:
From 93e9a18fbf09deb
From: Qualys Security Advisory <email address hidden>
Date: Tue, 23 Feb 2021 08:33:03 -0800
Subject: [PATCH 51/57] CVE-2020-28007: Link attack in Exim's log directory
We patch this vulnerability by opening (instead of just creating) the
log file in an unprivileged (exim) child process, and by passing this
file descriptor back to the privileged (root) parent process. The two
functions log_send_fd() and log_recv_fd() are inspired by OpenSSH's
functions mm_send_fd() and mm_receive_fd(); thanks!
This patch also fixes:
- a NULL-pointer dereference in usr1_handler() (this signal handler is
installed before process_log_path is initialized);
- a file-descriptor leak in dmarc_write_
did not close history_file_fd).
Note: the use of log_open_as_exim() in dmarc_write_
be fine because the documentation explicitly states "Make sure the
directory of this file is writable by the user exim runs as."
(cherry picked from commit 2502cc41d1d92c1
---
src/src/dmarc.c | 179 +++++++
src/src/exim.c | 14 +--
src/src/
src/src/log.c | 214 +++++++
test/stderr/0397 | 6 +-
5 files changed, 234 insertions(+), 182 deletions(-)
dmarc.c is not used in the default build configuration, but the patch
is broken and causes a failed build when it is enabled.
An easy way to test this is to download the source package, edit
the source file src/EDITME:
-# EXPERIMENTAL_
-# CFLAGS += -I/usr/
-# LDFLAGS += -lspf2
+EXPERIMENTAL_
+CFLAGS += -I/usr/
+LDFLAGS += -lspf2
-# EXPERIMENTAL_
-# DMARC_TLD_FILE= /etc/exim/
-# CFLAGS += -I/usr/
-# LDFLAGS += -lopendmarc
+EXPERIMENTAL_
+DMARC_TLD_FILE= /etc/exim4/
+CFLAGS += -I/usr/
+LDFLAGS += -lopendmarc
and also:
apt install libopendmarc-dev libspf2-dev
Custom builds are actually supposed to be supported by editing special files,
README.Debian.html says:
"Additionally, the source package offers infrastructure to build your own custom-tailored exim4-daemon-custom which exactly fits your special local needs. The infrastructure to do so is already in place, see debian/rules for instructions. "
Unfortunately, anyone doing that to enable dmarc will have a failing build.
Trisquel enables dmarc in its build, and also failed its build when pulling the update.
Here is the end of the build output which shows the failure:
gcc dmarc.c
gcc -c -g -O2 -D_LARGEFILE_SOURCE -fno-strict-
dmarc.c: In function 'dmarc_
dmarc.c:166:47: warning: suggest parentheses around '&&' within '||' [-Wparentheses]
if ( dmarc_policy == DMARC_POLICY_REJECT && action == DMARC_RESULT_REJECT
dmarc.c:168:47: warning: suggest parentheses around '&&' within '||' [-Wparentheses]
|| dmarc_policy == DMARC_POLICY_NONE && action == DMARC_RESULT_REJECT
dmarc.c:169:47: warning: suggest parentheses around '&&' within '||' [-Wparentheses]
|| dmarc_policy == DMARC_POLICY_NONE && action == DMARC_RESULT_
dmarc.c: At top level:
dmarc.c:211:1: error: static declaration of 'dmarc_
dmarc_
^~~~~~
In file included from dmarc.c:22:0:
dmarc.h:26:5: note: previous declaration of 'dmarc_
int dmarc_write_
^~
dmarc.c: In function 'dmarc_
dmarc.c:265:25: error: 'f' undeclared (first use in this function)
dmarc.c:265:25: note: each undeclared identifier is reported only once for each function it appears in
Makefile:811: recipe for target 'dmarc.o' failed
make[3]: *** [dmarc.o] Error 1
make[3]: Leaving directory '/nocow/
Makefile:35: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/nocow/
debian/rules:111: recipe for target 'override_
make[1]: *** [override_
make[1]: Leaving directory '/nocow/
debian/rules:293: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
debuild: fatal error at line 1152:
dpkg-buildpackage -rfakeroot -us -uc -ui -b failed
Related branches
- git-ubuntu bot: Approve
- Athos Ribeiro (community): Approve
- Canonical Server Reporter: Pending requested
-
Diff: 71 lines (+49/-0)3 files modifieddebian/changelog (+10/-0)
debian/patches/fix-coding-typo.patch (+38/-0)
debian/patches/series (+1/-0)
CVE References
Changed in exim4 (Ubuntu): | |
status: | New → Confirmed |
tags: | added: server-todo |
Changed in exim4 (Ubuntu Bionic): | |
importance: | Undecided → Low |
Changed in exim4 (Ubuntu Hirsute): | |
importance: | Undecided → Low |
Changed in exim4 (Ubuntu Focal): | |
importance: | Undecided → Low |
tags: | removed: server-todo |
description: | updated |
Changed in exim4 (Ubuntu Bionic): | |
assignee: | nobody → Bryce Harrington (bryce) |
status: | Triaged → Fix Committed |
try changing:
(host_checking || f.running_ in_test_ harness) ? " (not really)" : "");
in the patch to:
(host_checking || running_ in_test_ harness) ? " (not really)" : "");
to see if that fixes it...