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. https://github.com/fail2ban/fail2ban/commit/410a6ce5c80dd981c22752da034f2529b5eee844 https://github.com/fail2ban/fail2ban/commit/2ed414ed09b3bb4c478abc9366a1ff22024a33c9 https://github.com/fail2ban/fail2ban/security/advisories/GHSA-m985-3f3v-cwmm
Created fail2ban tracking bugs for this issue: Affects: epel-all [bug 1983224] Affects: fedora-all [bug 1983223]
This CVE Bugzilla entry is for community support informational purposes only as it does not affect a package in a commercially supported Red Hat product. Refer to the dependent bugs for status of those individual community products.
Isn't the vulnerability here only present when using the mail command from the mailutils upstream? The mail command in Fedora and EPEL comes from mailx. The upstream fail2ban patches which were applied add `-E 'set escape'` to the mail commands. But the mail command from mailx implements the `-E` option entirely differently. In mailx mail, `-E` takes no arguments; it skips mail which has an empty body. I think the upstream patch breaks any actions which call the mail command in Fedora and EPEL. There is more discussion of this in the upstream issue tracker here: https://github.com/fail2ban/fail2ban/issues/3059