fail2ban is a daemon to ban hosts that cause multiple authentication errors. In versions 0.9.7 and prior, 0.10.0 through 0.10.6, and 0.11.0 through 0.11.2, there is a vulnerability that leads to possible remote code execution in the mailing action mail-whois. Command `mail` from mailutils package used in mail actions like `mail-whois` can execute command if unescaped sequences (`\n~`) are available in "foreign" input (for instance in whois output). To exploit the vulnerability, an attacker would need to insert malicious characters into the response sent by the whois server, either via a MITM attack or by taking over a whois server. The issue is patched in versions 0.10.7 and 0.11.3. As a workaround, one may avoid the usage of action `mail-whois` or patch the vulnerability manually.
Patch in 0.11.3, please bump.
Note, the fix is broken at least with mailx. I've filed a bug upstream:
tl;dr their fix is not needed on systems where mail(1) comes from mailx, and in fact, breaks fail2ban on those systems.
I kept an eye on the upstream bug Hank (CC'd) linked to and he ended up concluding this is a bug in GNU mailutils .
It's now been fixed  there, so we should try backport the patch if they're not going to make a release shortly.
(In reply to Sam James from comment #2)
> I kept an eye on the upstream bug Hank (CC'd) linked to and he ended up
> concluding this is a bug in GNU mailutils .
> It's now been fixed  there, so we should try backport the patch if
> they're not going to make a release shortly.
Pinged upstream: https://savannah.gnu.org/bugs/index.php?60937#comment2.
Package list is empty or all packages have requested keywords.
Since this problem is confined to an interaction with mailutils, would it be appropriate to update RDEPEND to !net-mail/mailutils ? Either for any version (since no fixed ones are available yet) or for <= the current release since we expect the next release to include the already-committed fix (and even an -rN bump of mailutils that cherry-picks that fix would be sufficient)?
Huh, funny thing, fail2ban has no virtual/mailx dependency, and it doesn't seem that virtual is required by @system. So potentially one could have fail2ban with no mailer at all, and thus not be vulnerable because the relevant actions would not be functional.
The bug has been referenced in the following commit(s):
Author: Eray Aslan <firstname.lastname@example.org>
AuthorDate: 2021-07-30 07:07:37 +0000
Commit: Eray Aslan <email@example.com>
CommitDate: 2021-07-30 07:07:37 +0000
net-mail/mailutils: disable escapes in non-interactive mode
unlike other mail(1) implementations, mailutils mail command allowed
escape characters in non-interactive mode, resulting in CVE-2021-32749
in fail2ban package. backport fix for mailutils-3.12
Package-Manager: Portage-3.0.20, Repoman-3.0.3
Signed-off-by: Eray Aslan <firstname.lastname@example.org>
.../files/mailutils-3.12-disable_escapes.patch | 24 ++++
net-mail/mailutils/mailutils-3.12-r3.ebuild | 144 +++++++++++++++++++++
2 files changed, 168 insertions(+)
Ping. Looks like this can be fixed in fail2ban too?