OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: pop3
From: Christopher P. Lindsey (lindseyMALLORN.COM)
Date: Fri Apr 21 2000 - 14:50:28 CDT

> Qualcomms POP servers have this problem as well, on linux, solaris, etc.
> Except the lock file gets stored where ever your users mail is stored.
> /var/mail(on a sun) or where ever. I guess a nice solution would be to have a
> subdirectory with mode 700 permissions under /var/mail/locks or something like
> that where only the popper can write to. Or just ignore the lock if the owner
> of the lock file is diffrent thant the userid of the person popping their
> mail.

The terminology and extensions used here are getting a little muddled,
so I'm going to edify for others who may be confused:

   username : mailbox
   .username.pop : temporary mailspool location, effectively locks POP
   .username.lock: lockfile for "real" mailspool, locks LDA

qpopper has a compilation option to specify an alternate directory for
the .pop files. From the INSTALL file, section 7f for Qualcomm's
popper version 2.53:

   POP_DROP - When qpopper runs, it moves your mailspool to a
   temporary location (.user.pop). The default location is in the
   mail spool directory. /tmp is an alternative but is considered to
   be a security risk. A system reboot usually clears the temporary
   .user.pop files. For performance reasons, a sysadmin who has 1000+
   users can create a separate spool directory for qpopper files;
   /usr/spool/poptemp is preferable. Permissions should be the same
   as your mailspool with the same owner and group. Edit the value
   of POP_DROP in config.h.

   For Eg: #define POP_DROP "/usr/spool/poptemp/.%s.pop"

Of course, if /usr/spool/poptemp is set 1777 you still have problems with
other people creating .pop files if they have local access to the mail
server.

As you suggested, a better solution would probably be similar to what
procmail does -- if a lockfile is detected and is not owned by the user
for whom the temporary mailspool is being created (excepting root, as of
version 3.14), it is overwritten with a new one using proper permissions
and ownership.

qpopper 3.0 is out, and although it boasts "improved mailbox locking
code," a cursory glance at the code *appears* to reveal the same issues.
I'll set up a testbed to make sure.

Just to be clear, the worst thing that someone can do with this is a
DOS against POP requests for targeted users.

Chris