Subject: [Imap-uw] Vulnerability report. LIST command can cause high server load

From: Igor Tsurcanovsky <[email-masked]>
Date: Fri, 25 Nov 2005 18:02:48 +0200

Vulnerability report.

Product: UW imap-2004g

Risk: high

Vulnerability type: remote

Description:
Vulnerability exists due to insufficient checking of LIST command
arguments in IMAP service.

Effect:
Malefactor can cause ~100% processor load on a vulnerable system.

Vulnerability usage example:

* OK [CAPABILITY IMAP4REV1 LITERAL+ SASL-IR LOGIN-REFERRALS AUTH=PLAIN
AUTH=LOGIN] localhost IMAP4rev1 2004.357 at Fri, 25 Nov 2005 15:47:18
+0200 (EET)
0001 login test 1234
0001 OK [CAPABILITY IMAP4REV1 LITERAL+ IDLE NAMESPACE MAILBOX-REFERRALS
BINARY UNSELECT SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT
MULTIAPPEND] User test authenticated
0002 CREATE
"%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s
%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s"
0002 OK CREATE completed
0003 LIST
"%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s
%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s" "%s%s%s%s%s%s%s%s%s%s%s%s%s
%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%
s%s%s%s%s%s%s"

-- 
Best regards,
 Igor                            mailto:[email-masked]

_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: Mark Crispin <[email-masked]>
Date: Fri, 25 Nov 2005 13:16:49 -0800 (PST)

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-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: "Dan Mahoney, System Admin" <[email-masked]>
Date: Fri, 25 Nov 2005 17:43:54 -0500 (EST)

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'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.
>
> 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.
>
> 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:
> 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

--

"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
---------------------------