Marc Balmer wrote:
Indeed, I will try to test an update soon. BTW: we are using the OpenBSD/courier-imap combo for real large mailserver and don't see the problems that were described.
Yes, Marc, yes, Jason, neither did I see them on the Dual-Xeon. But the Dual-Xenon with 15k-SCSI is bigger iron, and the search finishes in below a minute easily. Don't get me wrong, my concern is not on the slow little bugger to not finish a search. My concern is how far this is an exploit, a DoS, eventually via dial-up, once it is known. What I seem to observe, is that a client can start a (full text==Entire Message) search at any moment she so desires. And it also seems, that this doesn't fall under the limitations of MAXPERIP. If what I have to assume, an attacker *could* resend a search request with a higher frequency or on a larger mailbox, or (DDoS) to a system with higher load, due to distributed searches (a plurality of searches on different accounts). The critical case seems to be, when a search takes longer than the TCP-timeout of the client. I think, in the cases described in here, this simply was not the case, due to 'big iron' and a somewhat randomised access and search by the independent users. What happens if someone gobbles together a 10- or 20-liner perl script that bombards the daemon with 'Entire Search'-requests of increasing frequency? Let's say, 60 seconds, 30 seconds, 10 seconds, 3 seconds, 2 seconds, 1 second. At one moment in time, our bigger irons will also fail to come up with a full search within these shorter periods. And when the script misses the result returned, it will resend the search. And so forth. Since this search cannot be performed within these few seconds, also this second request will not result in anything, and the script will repeat the search request ad infinitum. If someone wanted to try, do a 'Entire Message' search in Thunderbird (on a slow system with a large folder), and you'll see - surprise, surprise - that once per minute the client will connect and parse a (new) search request: Once per minute the status bar displays "Connecting to .... " "Sending Login information" for a short time, and the number of imapd processes goes up by one. Until exhaustion, maybe. And to me it looks like a possibly exploitable behaviour. The most straightforward solution: limit the number of concurrent searches per username to one.
Uwe
