Server Software and Configuration Services
Changes:
If you’re still using our old exim_deny dictionary attack solution in cPanel you should stop doing so and exclusively use the one provided by cPanel in cPanel v11. An exploit vector has been found and published for our old method:http://paste2.org/p/12037However, using that exploit method would be quite tricky because the exim_deny.pl script generates that lock file when the very first email passes through the ACL after installation and from then on it wouldn’t be possible to use the above exploit. That is, someone would have to create the symlink as described in the time between you adding the ACL into exim and the first email arriving. Alternatively, if you actively and indiscriminately delete files from /tmp, then the exploit could be applied between the time of deleting the lock file and the next email passes through exim.Such a short window of opportunity makes the exploit as described extremely unlikely as the hacker would have no idea when you’re going to install the ACL or to do it in advance of installation.We’re not aware of anyone being exploited through the use of this method.Incidentally, if you’re running csf, then lfd would pick up this type of issue through LF_DIRWATCHMany thanks to Billy for bringing this to our attention.The simplest way to remove our old exim_deny method is to select the option in WHM > Exim Configuration Editor > Reset ACL Config to Defaults and then remove the exim_deny files:
On servers that are running the perl modules that are a part of PathTools, MailScanner breaks with the recently released v3.26. If you’re suffering from this issue you’ll see MailScanner continually restarting. If you run MailScanner in –debug you’ll see it SegFault. In /var/log/messages you’ll see continual:
MailScanner: Process did not exit cleanly, returned 0 with signal 11
You can confirm which version of PathTools is installed using:
To fix this you need to downgrade PathTools to v3.2501:
Changes:
Changes:
Changes:
Upgrade by simply:
Changes:
Changes:
Changes:
We’ve released a new version of MSFE that will upgrade ClamAV and configure and install the clamd ClamAV Daemon process. The procedure will also reconfigure MailScanner to use clamd instead of the Mail::ClamAV perl module which will now no longer be required.We’ve made these changes for two reasons:1. It separates the dependency we’ve had on Mail::ClamAV keeping up with ClamAV developments. The current problem of incompatibility between v0.20 of Mail::ClamAV and ClamAV v0.92 has happened before and held back the upgrade to the latest version of ClamAV2. There is an added benefit that we’ve discovered where this change reduces each MailScanner child processes memory footprint by ~32MB. The clamd process uses around the same amount of memory, but there’s only a need for a single process. So, the saving on the typical system that runs 3 MailScanner children is ~64MBYou will notice that if you attempt to upgrade ClamAV through MSFE before upgrading MSFE itself, you’ll receive an error instructing you yo upgrade MSFE first.