This exploit is for a combination of fail2ban and `mail`. Reading how it works, it seems much more of a vulnerability for anything using the `mail` command than in fail2ban per se.<p>That ~! escape is really dangerous. What percentage of sysadmins are even aware of its existence? I can see how it can be useful, but there is a lot of potential for exploit if you aren't extremely careful.<p>The `mail` command shouldn't so easily accommodate executing arbitrary commands from input. The ~! escape should probably be either removed from `mail` entirely, or enabled only if you pass it a flag. It seems like a vestige from an earlier, more innocent time.<p>This isn't to absolve sysadmins who fail to sanitize their inputs, but let's not make their job so difficult.
For extra fun, there are (or at least were) multiple implementations of the mail command. The arguments were similar enough, but an old (and replaced) system at a previous employer required Heirloom mail/snail, not BSD because it actually intentionally used escape sequences like this.<p>In particular, it used one to add attachments (by giving the path).<p>We replaced it with Perl, getting rid of the shell script entirely (the whole stack was Perl).<p>Shell scripts really ought to use the sendmail command to send mail, but then you have to remember those obscure options to pass and generate the mail headers yourself, so it's understandable why no one does. (And probably handle dot-doubling).
How popular is this feature to send emails from fail2ban? I haven't heard about it until now, and I think I'd have a very noisy inbox if my fail2ban setup sent me mails about every blocked IP.
Since 0.8.1 Fail2ban uses Sendmail MTA for mailing so this is worrying only if you purposefully reverted to mail or upgraded from an older version. Recent deployments SEEM like they'd be fine out of the box.<p>The patches just update the action files to add escaping if you happen to be using mail.
Gentle reminder that you do not need fail2ban to block repeat connection attempts. Two IPTables lines will block any IPs connecting over a given rate in a given time. A third line logs it.
AFAIK the email alert feature is not enabled by default in fail2ban.<p>Is there any chance a default config of fail2ban in a typical Linux distribution would be vulnerable to this?
This makes me think to put something like<p>drop table prefixes;<p>in my ARIN WHOIS for a single /24 and see what happens to people scraping the database for marketing purposes
Interesting. This doesn't sound like that much of a vulnerability itself, but it does help clarify my thinking about SSH security.<p>Basically, SSH with proper configuration banning password auth is just fine and okay to be exposed to the internet. Extra logs from some failed attempts aren't really a big deal. If you want to make access more secure for it, that's okay, but I'd resist using complex on-server software for that which is likely to be less battle-tested and expose more attack surface. If you must do so, do things that are simple and/or off-server, like run on an alternate port or block network access for control ports at the firewall or security group level from any IP range but the ones you expect to be connecting from.
Does this remind anyone else of the exploit in The Cuckoo's Egg[0] whereby hackers escalate privilege by using GNU Emacs' mailutils?<p>[0] <a href="https://en.wikipedia.org/wiki/The_Cuckoo%27s_Egg_(book)" rel="nofollow">https://en.wikipedia.org/wiki/The_Cuckoo%27s_Egg_(book)</a>
Upstream has changed the behavior as a result.<p><a href="https://savannah.gnu.org/bugs/?60937" rel="nofollow">https://savannah.gnu.org/bugs/?60937</a><p>Kind of surprising as many *nix utilities that can shell out will offer "secure" modes to disable such an ability.
Looking at the patches, it seems running 'grep -rnw "mail -s" <fail2ban installation folder>, and replacing all found with "mail -E 'set escape' -s" is all that is needed.
I have never understood the point of Fail2ban other than feeling kinda smug.<p>If your SSH server is more at risk because an attacker simply has more attempts, surely your SSH server is not secure?<p>It is just adding another attack surface.
Is there a flag to disable tilde escapes, or a similar command that doesn't have this feature? The mail command is a really convenient way of sending mail in scripts.
This is the kind of thing that is never going to get patched on a lot of systems due to the obscurity of the tool in question. Really really bad.<p>At least higher profile stuff usually gets patched quickly.