Doug,
The only way to get complete protection from the exploit it to make sure
that IMail doesn't answer the Internet with SMTP. If you have IMail 8.x
or earlier, and you have customers connecting to IMail for SMTP, you
cannot sufficiently lock it down unless your firewall has some form of
IDS that detects this exploit.
Most exploits like this are run by 'script kiddies' doing a scan of IP
ranges. Even if you have your MX records pointed at a seperate gateway,
your IMail SMTP server will still be fully exposed. It is unlikely that
having such a gateway would provide any extra protection from this exploit.
This is the same as other past exploits of IMail. They don't spread by
E-mail, they spread by scripting.
Everyone that runs any mail server, regardless of brand, must absolutely
expect to have to patch their software for the latest exploits. Once
you no longer have a path to get a patch, you are in a lot of danger.
Ipswitch seemingly recognized in this case that the issues with 2006
cause a situation where there is not a suitable upgrade path for a large
number of users. I still don't believe that this has been fully handled
appropriately as the patch is not listed on their Downloads page, and no
mailings have been sent out to those under a current service agreement.
Regarding previous versions, there were other exploits for versions
prior to 8.15 HF2, so running something earlier is not wise regardless
of this particular issue. 8.15 HF2 has a killer message vulnerability
that causes Queue Manager to crash and has been triggered by some
messages in the wild. I wouldn't think that being on 8.15 HF2 would be
wise, though not for simply the reason that Ipswitch is not committed to
a patch.
I think that it would be wise for Ipswitch to reevaluate their approach
to vulnerability patches. It is unreasonable to think that customers
can keep up with dot-releases because functionality does change with
these and a mail server is a critical tool for many organizations.
These dot-releases tend to come out about three times a year, and that
just doesn't work for everyone. I believe that they should seek to
provide patches for vulnerabilities for all dot-releases going back for
1 to 2 years. The two year number is appropriate because of the issues
with upgrading, and they aren't isolated to just the recent
circumstances. I don't think that it would be fully unreasonable to not
provide patches to older versions without a service agreement, but for
reasons that I previously stated, it would be a net positive for them to
do so. They certainly would have avoided this situation. I spoke up
about this on 9/12 when the vulnerability first came up, but they waited
until it was spreading in the wild and the message list lit up before
responding to the issue. As a result, Ipswitch has lost goodwill,
whereas if they had provided the patch back then, they would have gained
goodwill.
Matt
Doug Traylor wrote:
So am I to understand that ASSP somehow prevents the vulnerabtility
from being a problem?
With the recent report of the exploit getting through IMGate, this is
still a good question. Is there anybody using ASSP directly in front
of IMail, that has suffered from this exploit? Will the delaying
option in ASSP be a sufficient deterrent? Assuming the exploit uses a
valid recipient and passes all ASSP connection tests, will the
malicious rcpt command be passed unmolested from ASSP to Imail? Does
anyone have a record of a successful exploit or exploit attempt that
we could use to generate a blocking filter?
Thanks,
Doug Traylor
MIS Department
Harbison-Fischer Mfg. Co.
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive:
http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
