On Fri, 25 Nov 2005, Mark Crispin wrote:
I routinely keep 5000 messages in my inbox which causes a bit of a stir
when I open it (although I only use pine, not imapd). If you don't want
the intensive load, then set process limits. (consult the manual for your
particular OS). Since it's only a LIST, it's non-destructive if the
process is terminated during it. (albeit, if you're limiting on total CPU
time it's possible that you could cross over that threshhold sometime
AFTER the LIST).
The only way I see this as a potential DOS is if there are other services
which shut themselves down under high load (sendmail springs to mind).
-Dan
In general, it is more helpful to send a report of claimed vulnerabilities to
the developer privately, prior to a public announcement. It is also helpful
to avoid public announcements during national holidays in the developer's
country; November 24 and 25 are national holidays in the USA.
I have examined your report, and have reproduced the CPU-intensive LIST
operation. However, I do not see how this is a "vulnerability".
The problem has nothing to do with "%" in the mailbox name, or the "%s"
combination. It's the sheer number of wildcards in the pattern.
I've been running this LIST for a few hours now. It's quite amusing. The
server is progressing in the pattern-matching algorithm on the strings in
question.
The problem is that the pattern-matching algorithm makes no attempt to
optimize large numbers of wildcards (it's effectively doing a very large
"Towers of Hanoi") or cancel out cases where the non-wildcard part of the
search pattern is longer than the candidate string.
There is no "%s" sprintf() issue, or other buffer overflow or improper memory
access, that I can see. The system running this CPU-consuming imapd process
is otherwise running smoothly with no noticable delays. The schedulers in
most operating systems do not allow CPU-intensive tasks to have a substantial
impact on the performance of interactive tasks. The imapd is not consuming
much memory either.
Consequently, as far as I can tell, the principal impact is to the imapd
session doing the ridiculous wildcard.
If the above is a correct description of the issue, then I do not consider it
to be a vulnerability, much less a "high risk" vulnerability. It does not
appear to:
. allow access to unauthorizated areas of the system
. allow execution of arbitrary code
. substantially impact system performance
Have I missed something? If so, please tell me what it is.
I would certainly reconsider my response in light of additional information.
As a practical matter, it may be worthwhile to add a limitation on the number
of wildcards permitted to something that can be solved in a reasonable amount
of time.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
--
"It's buttery kettle ASS corn!"
-Dan Mahoney, Ezzi Computers,
10/22/03, 2AM
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144 AIM: LarpGM
Site: http://www.gushi.org
---------------------------
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
