<story><title>Fail2ban – Remote Code Execution</title><url>https://research.securitum.com/fail2ban-remote-code-execution/</url></story><parent_chain></parent_chain><comment><author>loudmax</author><text>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.&lt;p&gt;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&amp;#x27;t extremely careful.&lt;p&gt;The `mail` command shouldn&amp;#x27;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.&lt;p&gt;This isn&amp;#x27;t to absolve sysadmins who fail to sanitize their inputs, but let&amp;#x27;s not make their job so difficult.</text></comment>
<story><title>Fail2ban – Remote Code Execution</title><url>https://research.securitum.com/fail2ban-remote-code-execution/</url></story><parent_chain></parent_chain><comment><author>derobert</author><text>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&amp;#x2F;snail, not BSD because it actually intentionally used escape sequences like this.&lt;p&gt;In particular, it used one to add attachments (by giving the path).&lt;p&gt;We replaced it with Perl, getting rid of the shell script entirely (the whole stack was Perl).&lt;p&gt;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&amp;#x27;s understandable why no one does. (And probably handle dot-doubling).</text></comment>