Bug 16749 – bad permissions in mailbase (security: local DOS)

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Stanislav Brabec 2003-03-03 11:49:31 UTC]

Package: mailbase-0.00-r5

searching for problems in gnu-pop3d (not from Gentoo - mailbox stays
locked after fetch), I found following local DOS, introduced in
mailbase-0.00-r5.ebuild (marked as fix of #8029). There were clean
discussion for this bug, but fix is bad (typo?):

fperms 1777 /var/spool/mail

There is simple code, which can lock all active mail accounts:

cd /var/spool/mail
for i in * ; do touch $i.lock ; done

Basically 1777 is illegal permissions for /var/spool/mail.

There are two legal setups for this directory, which can be found in
other UNIX systems:

755 root any_group
Only root and setuid root binaries can access mail locks (not
recommended because setuid root)

775 root mail
Only root and setgid mail binaries can access mail locks

Second one is more secure, because apps don't need root permissions.

Most applications can succeed with both upper mentioned schemes (and
also 1777) and have autodetection of proper mode (except 1777) and use
helpers for lock access (for example mutt_dotlock).

Sticky flag is not OK - 1777 it can cause also other problems, not only DOS attacks.
For example, there is a GNU pop3d locking algorithm:
create lock (as root/mail)
setuid user
remove lock (as user/mail) - EPERM

[Comment 1 Stanislav Brabec 2003-03-03 11:50:39 UTC]

Created attachment 8903 [details, diff]
mailbase.diff

This patch fixes permission to wise value.

[Comment 2 Daniel Ahlberg (RETIRED) 2003-03-05 04:50:30 UTC]

raker: Do you see any problems with changing the mode on /var/spool/mail? 

[Comment 3 Stanislav Brabec 2003-03-18 10:24:42 UTC]

Please look at discussion of bug 8029. Comment #1 from [e-mail] recommends 775, not 1777. I think, that changing permissions to 1777 was a mistake.

[Comment 4 Daniel Ahlberg (RETIRED) 2003-08-05 16:25:04 UTC]

fixed in -r6 

[Comment 5 Danek Duvall 2004-12-16 13:52:50 UTC]

This just went stable, and I'm seeing this from pine:

        [Folder vulnerable - directory /var/spool/mail must have 1777       protection]

Is there a bug in pine, does it just need recompilation, or what?  It seems to work, regardless.

[Comment 6 Thierry Carrez (RETIRED) 2004-12-17 02:55:31 UTC]

Danek : you should post a new bug for the PINE warning. As far as this bug is concerned everything is now ok. I have no clue why PINE complains about the new perms... but net-mail people might have an idea.

[Comment 7 Danek Duvall 2004-12-18 10:03:24 UTC]

I filed bug 74847 for this problem.

[Comment 8 splite 2005-01-26 08:27:19 UTC]

Perhaps up and changing the perms on /var/spool/mail without verifying that the clients didn't break wasn't such a great idea...  Yes, someone can DoS mail readers by creating .lock files in the mail spool, but that someone is very easy to hunt down and kneecap as their UID is all over the files.

As for the gnu-pop3d problem, that's arguably a bug in their code.  They should drop perms before creating the lock file.

I'm not advocating a 1777 mailspool, just pointing out that you can't arbitrarily change the perms and expect all the sundry mail clients to be okay with it.

[Comment 9 Jonathan Geisler 2005-02-05 10:03:03 UTC]

I just upgraded to -r6 yesterday and this messed mutt up.  Before finding this bug I changed the permissions back to 777 and things just worked.

The problem was that mutt believed the inbox was readonly and I couldn't toggle it to write.  Since I owned the file in /var/spool/mail and could modify it, I'm not sure exactly what the problem was.

[Comment 10 Simon Matthews 2005-03-15 13:09:22 UTC]

I believe this breaks Postfix. 

Postfix delivers mail with the privileges of the recipient email. This, for email to be delivered to a new user, the new user must be in the "mail" group. If all users are in the "mail" group, then the DOS attack can still be performed. 

Postfix does NOT use a setgid mail binary to deliver email. It drops privileges to that of the recipient user.