Bugtraq mailing list archives

Re: pop3


From: lindsey () MALLORN COM (Christopher P. Lindsey)
Date: Fri, 21 Apr 2000 14:50:28 -0500


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


Current thread: