Bug 11065

This is all done using imap-4.7-7 packages.

#1
I don't know why this is, but it seems that lockfiles for a user that are
created in /tmp have the same name each time or very similar, like 1 char
difference, when the user logs into their pop3 mailbox until the system is
rebooted.  Here is what I mean:

On linux.local the machine running ipop3d:
[root@linux mail]# l /tmp/.*
drwxrwxrwt   24 root     root         3072 Apr 26 20:33 /tmp/.
drwxr-xr-x   26 root     root         1024 Apr 21 20:49 /tmp/..
drwxrwxrwt    2 root     root         1024 Apr 25 18:48 /tmp/.ICE-unix
drwxrwxrwt    2 root     root         1024 Apr 25 18:48 /tmp/.X11-unix
drwxrwxrwt    2 xfs      xfs          1024 Apr 26 14:20 /tmp/.font-unix

[root@linux mail]# l /var/spool/mail
total 437
drwxrwxr-x    2 root     mail         1024 Apr 26 20:06 .
drwxr-xr-x   17 root     root         1024 Aug  2  1998 ..
-rw-rw----    1 db       mail          482 Apr 24 22:36 db
-rw-rw----    1 sb       mail         1140 Jan 24 20:48 sb
-rw-rw----    1 news     mail       207836 Mar  5 20:30 news
-rw-------    1 root     root            0 Apr  5 13:26 root
-rw-rw----    1 user     mail          533 Apr 26 20:07 user
-rw-rw----    1 www      mail       218724 Feb 23 23:30 www

On king.local client machine:
[user@king user]# telnet linux 110
Trying 192.168.0.3...
Connected to linux.local (192.168.0.3).
Escape character is '^]'.
+OK POP3 linux.local v7.64 server ready
user sb
+OK User name accepted, password please
pass testpass
+OK Mailbox open, 1 messages

Back on linux.local:
[root@linux mail]# l /tmp/.* -d
drwxrwxrwt   24 root     root         3072 Apr 26 20:37 /tmp/.
drwxr-xr-x   26 root     root         1024 Apr 21 20:49 /tmp/..
-rw-rw-rw-    1 user     users           4 Apr 26 20:37 /tmp/.301.29057
drwxrwxrwt    2 root     root         1024 Apr 25 18:48 /tmp/.ICE-unix
drwxrwxrwt    2 root     root         1024 Apr 25 18:48 /tmp/.X11-unix
drwxrwxrwt    2 xfs      xfs          1024 Apr 26 14:20 /tmp/.font-unix

The lockfile /tmp/.301.29057 is created and after user logs off, it is
gone:

[root@king rfc]# l /tmp/.* -d
drwxrwxrwt   24 root     root         3072 Apr 26 20:42 /tmp/.
drwxr-xr-x   26 root     root         1024 Apr 21 20:49 /tmp/..
drwxrwxrwt    2 root     root         1024 Apr 25 18:48 /tmp/.ICE-unix
drwxrwxrwt    2 root     root         1024 Apr 25 18:48 /tmp/.X11-unix
drwxrwxrwt    2 xfs      xfs          1024 Apr 26 14:20 /tmp/.font-unix

User logs back into account again:

[root@king rfc]# l /tmp/.* -d
drwxrwxrwt   24 root     root         3072 Apr 26 20:45 /tmp/.
drwxr-xr-x   26 root     root         1024 Apr 21 20:49 /tmp/..
-rw-rw-rw-    1 user     users           4 Apr 26 20:45 /tmp/.301.29057
drwxrwxrwt    2 root     root         1024 Apr 25 18:48 /tmp/.ICE-unix
drwxrwxrwt    2 root     root         1024 Apr 25 18:48 /tmp/.X11-unix
drwxrwxrwt    2 xfs      xfs          1024 Apr 26 14:20 /tmp/.font-unix

Lockfile returns with same name.  Why? I don't know.  Each user gets a
different lockfile name, but it always seems to be the same until system
reboots which allows people to do this:

[eviluser@linux eviluser]# touch /tmp/.301.29057

so when user tries to log into mail account:

[user@king user]# telnet linux 110
Trying 192.168.0.3...
Connected to linux.local (192.168.0.3).
Escape character is '^]'.
+OK POP3 linux.local v7.64 server ready
user user
+OK User name accepted, password please
pass testpass
-ERR Can't get lock.  Mailbox in use
Connection closed by foreign host.

Nifty little temporary DoS.  All a user has to do is check for the name of
another user's lockfile and touch it when he/she logs off.  I haven't had
time to look at this very closely nor look at lockfile functionability, but
I did try this on a slackware machine with same version of imap and ipop3d
and it exibited the same behaviour.

#2 Obscure, Theoretical, but could happen.

If a user's mailbox is symlinked to the user's lockfile, the process which
opened the mailbox hangs and has to be killed locally because it won't
accept commands and the user cannot reconnect because the new process will
try to lock the mailbox fail and then fail to get the old process to cough
up the lock file and thus loging into ipop3d fails.  This kind of DoS would
only be workable if the following is true:

1. /var/spool/mail is chmod 1777 like ipop3d wants (i.e. in logs: Apr 26
20:21:55 linux ipop3d[5389]: Mailbox vulnerable - directory /var/spool/mail
must have 1777 protection
I know alot of people make it 1777 to get rid of annoying messages ipop3d
spews.  The filesystem package set /var/spool/mail at 0755 and linuxconf
wants it 1775.  Can't have it both ways, 1777 or 1775, gotta pick.

2. While the user was logged into ipop3d his/her mailbox was removed by
another process or program the user ran or had running (i.e. another window
with a different mail prog or something like that)

If those are true than a malicious user could ln -s /tmp/<user's lockfile>
/var/spool/mail/<user> and tada when user tries to log off ipop3d it is no
longer responding and must be killed by root as it is running under uid of
nobody.

I figured this one out because I forgot I had a program that checked my
mail every hour running in the background and it moved my mail to my home
directory while I was on the pop port.  After looking at my maillog I
figured out the problem and found I could fool around with it.  Another
interesting thing about this is that a user can get imap and ipop3d process
both running unresponsive by logging in this way:

+OK POP3 linux.local v7.64 server ready
user linux:user
+OK User name accepted, password please
pass testpass
+OK Mailbox open, 1 messages

using the 'user <host>:<user>' causes ipop3d to startup an imapd and use
that to read the mail.  In that way you can get both all screwed up:P

#3

Allowing clients to use imap services through pop3 like mentioned above
circumvents IP restrictions imposed on the imap port (i.e. access is
restricted to localhost) because pop connects to the imap port using
address 127.0.0.1 thereby bypassing any imposed IP restrictions on the imap
port.  Just food for thought.

Anyway none of these are DoS's that bring down IMAPD or POPD altogether,
they just DoS certain users, so not a huge problem by any means.


-Stan Bubrouski