mailing list archives
Re: Solaris /usr/bin/mailx exploit (SPARC)
From: woods () weird com (Greg A. Woods)
Date: Wed, 16 May 2001 15:07:34 -0400 (EDT)
[ On Tuesday, May 15, 2001 at 14:47:02 (-0700), Tobias J. Kreidl wrote: ]
Subject: Re: Solaris /usr/bin/mailx exploit (SPARC)
Andrew Hilborne <andrew.hilborne () uk xo com> wrote on
Tue, 15 May 2001 14:15:45 +0100:
Just how do you force 0600 on mailboxes which don't exist (many MUAs
remove empty mailboxes?)
Since you cannot easily do this, at the very least a malicious user
should be able to steal other users' mail. I think.
1) The permissions 1777 on /var/mail should allow empty mailboxes to
remain under most circumstances. One should be careful what
IMAP and POP services are running on your machine and how
they handle this.
2) When a new user account is first established, it is imperative that
a mailbox be created at that time with the proper ownerships and file
3) A cron job can help monitor any discrepancies between existing and
desired file attributes of mailboxes in /var/mail and rectify them on
That's all true, in so far as it goes, but it does leave the system open
to far more risk than is necessary in that the local delivery agent must
still run as root.
Having implemented what I hope to be a secure and portable
fopen_as_user() function I can assure you that even the apparently
simple job of doing local delivery from a privileged position isn't
really all that simple at all. If the calling process isn't expecting
to exit within such a function then you have to fork() and with careful
error checking and few comments the resulting code is well over 200
Indeed if you're going to go to all the trouble of pre-creating
mailboxes and ensuring that empty ones are left behind by all mail
reading agents then it's trivial to implement setgid-mail delivery on
even systems which don't allow ordinary users to use chown(2).
I.e. it's trivial, even on such systems, to avoid having to use root
privileges in any part of the local mail system!
In my estimation the risk resulting from a successfull group-ID "mail"
compromise is still almost infinitely less than the risk of a root
compromise, regardless of what the system involved is used for!
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods () acm org> <woods () robohack ca>
Planix, Inc. <woods () planix com>; Secrets of the Weird <woods () weird com>