CVE-2021-32749

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.

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. (CVE-2021-32749)

This update for fail2ban fixes the following issues:

• CVE-2021-32749: prevent a command injection via mail command (boo#1188610)

• Integrate change to resolve boo#1146856 and boo#1180738

Update to 0.11.2

• increased stability, filter and action updates

New Features and Enhancements

• fail2ban-regex:
  • speedup formatted output (bypass unneeded stats creation)
  • extended with prefregex statistic
  • more informative output for datepattern (e. g. set from filter) - pattern : description
• parsing of action in jail-configs considers space between action-names as separator also (previously only new-line was allowed), for example action = a b would specify 2 actions a and b
• new filter and jail for GitLab recognizing failed application logins (gh#fail2ban/fail2ban#2689)
• new filter and jail for Grafana recognizing failed application logins (gh#fail2ban/fail2ban#2855)
• new filter and jail for SoftEtherVPN recognizing failed application logins (gh#fail2ban/fail2ban#2723)
• filter.d/guacamole.conf extended with logging parameter to follow webapp-logging if it's configured (gh#fail2ban/fail2ban#2631)
• filter.d/bitwarden.conf enhanced to support syslog (gh#fail2ban/fail2ban#2778)
• introduced new prefix {UNB} for datepattern to disable word boundaries in regex;
• datetemplate: improved anchor detection for capturing groups (^...);
• datepattern: improved handling with wrong recognized timestamps (timezones, no datepattern, etc) as well as some warnings signaling user about invalid pattern or zone (gh#fail2ban/fail2ban#2814):
  • filter gets mode in-operation, which gets activated if filter starts processing of new messages; in this mode a timestamp read from log-line that appeared recently (not an old line), deviating too much from now (up too 24h), will be considered as now (assuming a timezone issue), so could avoid unexpected bypass of failure (previously exceeding findtime);
  • better interaction with non-matching optional datepattern or invalid timestamps;
  • implements special datepattern {NONE} - allow to find failures totally without date-time in log messages, whereas filter will use now as timestamp (gh#fail2ban/fail2ban#2802)
• performance optimization of datepattern (better search algorithm in datedetector, especially for single template);
• fail2ban-client: extended to unban IP range(s) by subnet (CIDR/mask) or hostname (DNS), gh#fail2ban/fail2ban#2791;
• extended capturing of alternate tags in filter, allowing combine of multiple groups to single tuple token with new tag prefix <F-TUPLE_, that would combine value of <F-V> with all value of <F-TUPLE_V?_n?> tags (gh#fail2ban/fail2ban#2755)

• Fixes

• [stability] prevent race condition - no ban if filter (backend) is continuously busy if too many messages will be found in log, e. g. initial scan of large log-file or journal (gh#fail2ban/fail2ban#2660)
• pyinotify-backend sporadically avoided initial scanning of log-file by start
• python 3.9 compatibility (and Travis CI support)
• restoring a large number (500+ depending on files ulimit) of current bans when using PyPy fixed
• manual ban is written to database, so can be restored by restart (gh#fail2ban/fail2ban#2647)
• jail.conf: don't specify action directly in jails (use action_ or banaction instead)
• no mails-action added per default anymore (e. g. to allow that action = %(action_mw)s should be specified per jail or in default section in jail.local), closes gh#fail2ban/fail2ban#2357
• ensure we've unique action name per jail (also if parameter actname is not set but name deviates from standard name, gh#fail2ban/fail2ban#2686)
• don't use %(banaction)s interpolation because it can be complex value (containing [...] and/or quotes), so would bother the action interpolation
• fixed type conversion in config readers (take place after all interpolations get ready), that allows to specify typed parameters variable (as…

These are all security issues fixed in the fail2ban-0.11.2-3.1 package on the GA media of openSUSE Tumbleweed.

Jakub Żoczek discovered that certain Fail2ban actions handled whois responses in an insecure way. If Fail2ban was configured to use certain mail actions like 'mail-whois' on a target system, a remote attacker who was able to control whois responses to this target system could possibly execute arbitrary code.