Closed Bug 446411 Opened 16 years ago Closed 15 years ago

Thunderbird treats extensive searches as connection failures, accidentally DoSes the IMAP server

Categories

(MailNews Core :: Networking: IMAP, defect)

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 409259

People

(Reporter: udippel, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.8.1.10) Gecko/20071230 Firefox/2.0.0.10
Build Identifier: Firefox/2.0.0.10

With large mailboxes, searches like 'Entire Message', Thunderbird will assume a link failure after mailnews.tcptimeout (default 60) and request a new one. 
I have shown how this can be used to launch a DoS attack in
http://permalink.gmane.org/gmane.os.openbsd.ports/30688

Problem: While mailnews.tcptimeout (default 60) is maybe useful, Thunderbird ought to have another means to evaluate the success of a long search. It is wrong to repeat the search request over and over, until - depending on the imap daemon, the server runs out of resources. In the case described, the search would take 2.5 minutes, but never succeed, because in the end the daemon ran close to 100 searches und would finally collapse, due to the repeated search request, once per minute ('60').
The fastest solution would be a second time-out for searches 'Entire Message', like mailnews.searchtimeout with a default of well above 60 seconds, with an internal counter giving up searches after a limited number of failures; just like a connection timeout is handled. In the post, one can see that Thunderbird has tried for more than 3 hours, spawning a search once per minute. That is sick.
Also, Thunderbird has not stopped searching, despite all my efforts to abandon the search, clicking another folder, etc. This is another program error. After 3 or 5 requests, especially with navigation off the folder, the user must at least be asked if the search is to be abandoned. As of now, to my knowledge, Thunderbird offers no such means, meaning that a DoS is accidentally launched, until the server admin kills the daemon.

Reproducible: Always

Steps to Reproduce:
1. Search 'Entire Message' in large folder, taking more than 1 minute
2.
3.
Actual Results:  
Search never finishes, taking eventually daemon down

Expected Results:  
Thunderbird notices that the search is vain, after an extended time, and most importantly, does not handle the missing result as TCP-timeout.
The user should have another knob to turn to extend the time of searches in case of large mail-boxes.
Group: core-security
Component: Preferences → Networking: IMAP
Product: Thunderbird → Core
QA Contact: preferences → networking.imap
Summary: Thunderbird treats extensive searches as connection failures → Thunderbird treats extensive searches as connection failures, accidentally DoSes the IMAP server
Flags: blocking-thunderbird3?
Bug 409259 already exists for COPY/APPEND command case. Setting dependency instead of DUPing, because proposal of new option like mailnews.searchtimeout is involved in this bug.
Depends on: 409259
Bug 409259 also covers LIST operations, and now has a "workaround" patch (just increase default timeout to something larger than most server-side timeouts) -suggest to DUP.
A new option just for searches will not help, "search" is just a special case of the more general problem, but equally will eventually overload the server (even if no duplicate messages are being generated). Also got reported as a "server DoS" in bug 332309.
marking as dupe as i agree that the general imap problem seems to cover this specific issue.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Product: Core → MailNews Core
Flags: blocking-thunderbird3?
You need to log in before you can comment on or make changes to this bug.