[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mail.app DoS/BAD parse error: invalid message sequence number



FYI to everyone: Bug 47941 has been implemented in the upcoming 6.0.8:

Implement defensive measure options against possible DOS attacks
http://bugzilla.zimbra.com/show_bug.cgi?id=47941
        After 5 consecutive invalid commands, drop the IMAP connection.  
This should protect against confused clients like Mail.app.
FIXED: 6.0.8

The current planned release date for 6.0.8 is included on the Product Management Portal (targeted Aug 17): http://pm.zimbra.com
http://pm.zimbra.com/pm_release.php?rel=6.0&prod=zcs

This is planned to protect ZCS from the perceived Apple mail client bad command problems.

+++ Part 2:
As far as Apple goes, although I believe they still want yet more data. If any sites can set Zimbra IMAP to debug and provide data showing the BAD PARSE client and server commands demonstrated on each of these different models (or any versions of these models):
It would very much help. What you'd need to do is put a zimbra.imap account logger into debug on known accounts, then capture the entire IMAP logs from mailbox.log for those users:
# su - zimbra
$ zmprov aal username@domain.com zimbra.imap debug
It can be removed with the following:
# su - zimbra
$ zmprov ral username zimbra.imap
Then provide those logs to Zimbra, and we'll submit the further info to Apple. Thanks very much.

Sincerely,
-thom


Hi David,

I think the idea of performing defense measures based on certain client behavior is reasonable, and I filed an enhancement request Bug 47941 [https://bugzilla.zimbra.com/show_bug.cgi?id=47941]. When and how this gets implemented - such as dropping the IMAP connections or disabling (temporarily or permanently) user accounts - needs to be discussed further by the Engineering team, as there are complexities such as whether or not proxies are in use, how NIO_IMAP or thread pools handle connections, and what behavior (and how many actions) is considered an attack versus simply a nuisance. Defensive measures, when implemented, would likely ultimately result in loss of service for that user for at least a period of time, and one can be certain that this technique would, at times, get triggered prematurely or in unexpected or minor cases. So what is currently thought to be excessive log growth, may then turn into end user calls or complaints. The irony of using protective techniques against perceived denial of service attacks is that these techniques often seek to protect "the service" by limiting the service available to one or more source IPs or accounts, and therefore protect service by denying it; there is a careful balance here, and in some cases, these sorts of protections are best implemented by a specialty network or firewall device at the perimeter of the network.

As Xueshan and Zimbra Engineering have noted, we do not believe at this time that the BAD parse problem increases load significantly or has other significant performance or functional impact on the server other than increasing the mailbox.log size. I cannot speak for Apple, but our Engineering/QA team has tested this scenario and believes the server impact to be minimal.

Sincerely,
-thom



Hi Thom-
  Thanks for the confirmation. We're certainly happy to provide any more info we can. A few followup questions, if I might:

1) has Zimbra or Apple been able to reproduce the problem following the steps we detailed? I ask because we can cause this behavior to happen every single time we try them here. As far as I know, we're using the latest shipping version of Mail.app to do so. If this is as readily reproducible outside our environment as it is here, I would think Apple could immediately see the problem in action.

2) could you speak to the question of the Zimbra server being able to mitigate bad client "attacks" (as Xueshan called them). Is that something Zimbra is considering doing? i'm wondering if it could be as simple as keeping a counter of the number of attempts to access data on messages that don't exist. If a client does that N times, you drop that one IMAP connection. I'm not claiming that this is a general protection, but I'm reasonably confident that it would immediately nip this particular problem in the bud based on the other responses in this email thread.

I'm especially interested in #2 just because it wouldn't leave my server at the mercy of another company releasing a patch in N months or the unknown number of users who don't actually apply released patches. As I understand it from various unofficial Apple sites, the next OS patch is pretty close to release (not to mention iPhone and iPad revs). This means we're in for a considerable wait before a Mail.app patch could even see the light of day.

          -- dNb