* Uwe Dippel wrote: > 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).
It will be one of your users. Looking at the logfiles you will quickly identify him. > 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. I suggest that you take your concern upstream, i.e. to the courier developers. Here, we more or less only package what they provide us with. > > Uwe > - Marc
