MDaemon Critical vulnerability (versions 11, 12 and 13)

Alt-N posted a fix to a recently discovered vulnerability, MDaemon Security Bulletin – MD102412, listing MDaemon versions 11, 12, and 13 as being affected by a flaw that was discovered during internal testing.

If you run one of the affected versions, please visit http://www.altn.com/Support/SecurityUpdate/ to find an updated build and install the update immediately. Builds are available for customers running older versions even if your upgrade protection has already expired, so there is no reason to not deploy this release immediately.

Per Alt-N’s FAQ on MD102412, MDaemon versions prior to MDaemon 11.0.0 are not affected by this issue.

Disabling weak SSL protocols and ciphers

MDaemon relies upon Windows to provide SSL services. This includes modern SSL versions as well as some older, less secure protocols and cyphers. You can modify the Windows registry to increase the security of your SSL implementation, at the cost that very old clients may have issues.

To disable protocols PCT1 and SSL2.0, use the Disable-PCT-1.0-SSL-2.0-and-weak-ciphers.reg file available in RAR or ZIP format. Note that the RAR has an authenticity verification signature, signed by Dave Warren and should not be used if this signature is missing.

The contents of the .REG are located below, be aware that some word-wrap issues might occur. Please use the RAR or ZIP downloads above.

To disable PCT 1.0 and SSL 2.0:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]

And to remove weak ciphers:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 128/128]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]
“Enabled”=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168]

Please be sure to create a full backup of your system before proceeding, modifying the Windows Registry can be dangerous and can result in unexpected behaviours.

(don’t) Drop connection if transmission exceeds…

MDaemon currently has two features that attempt to limit the size of messages that MDaemon will accept, both located under Setup –> Default Domain –> Servers:

  1. … refuses all messages larger than (and a per-domain feature that does the same)
  2. … drop connection if transmission exceeds

This article covers the second, the “drop connection if transmission exceeds” option. In short, you probably shouldn’t use it, or should think very careful before enabling it as it will probably not do what you want.

Specifically, do not attempt to use this feature to limit the size of message that you’ll accept, and do not use this feature to try to reduce your server’s bandwidth usage, it won’t work and it will cause your bandwidth usage to go way up. Oh, and it won’t inform users of the problem so they’ll manually retry sending messages, compounding the problem.

The “drop connection…”options scattered around MDaemon all have potential to increase bandwidth use in certain cases, but this is one of the worst because it only kicks in during transmission of large messages. As a result, this option potentially causes dramatic increases in bandwidth usage due to the way SMTP works. Most SMTP clients (senders) use the SIZE parameter in the MAIL FROM command, a few use it in the EHLO response. These senders are smart enough to not even try sending a too-large message, so they don’t matter here. For the few that don’t support verifying maximum sizes before sending messages, they get to the DATA stage and start sending a huge message and one of two things happens:

  1. If it gets to the end of the DATA phase, MDaemon can return a 5xx “too-large” error and the sender bounces the message back.
  2. If something happens during the DATA phase (connection problem, firewall, MDaemon willfully drops the connection) the sender puts the message in their queue and retries sending it again. And again. And again. And again. And again. And again. And again. And again. And again. And again. And again.

    And again.

Using “Drop connection if transmission exceeds…” is almost always going to be a very idea and going to drive your bandwidth usage up dramatically if you attempt to use it to limit the size of message that MDaemon will process.

The only time it’s useful is this: If a sender actively attempts a disk-fill attack, where they open a ton of sessions at once and try to cause MDaemon to write GBs of messages until the disk is full. You can protect against this type of attack by having a reasonable amount of drive space, and by setting this limit very high (I’d suggest in the 50MB range, and at least 2x-3x of the maximum message size you’ll receive)