[14629] in bugtraq
Re: pop3
daemon@ATHENA.MIT.EDU (Christopher P. Lindsey)
Mon Apr 24 12:14:00 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-Id: <20000421145028.G30678@mallorn.com>
Date: Fri, 21 Apr 2000 14:50:28 -0500
Reply-To: "Christopher P. Lindsey" <lindsey@MALLORN.COM>
From: "Christopher P. Lindsey" <lindsey@MALLORN.COM>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <8782.956247808@www5.gmx.net>; from spoon spoon on Thu, Apr 20,
2000 at 06:23:28PM +0200
> 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
