Bugtraq 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 permissions. 3) A cron job can help monitor any discrepancies between existing and desired file attributes of mailboxes in /var/mail and rectify them on the fly.
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 lines long! 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>
Current thread:
- Re: Solaris /usr/bin/mailx exploit (SPARC) Casper Dik (May 15)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Johann Klasek (May 15)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Greg A. Woods (May 16)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Andrew Hilborne (May 15)
- MUAs that delete spoolfiles (was Solaris /usr/bin/mailx exploit (SPARC)) Rich Lafferty (May 16)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Greg A. Woods (May 15)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Dan Astoorian (May 15)
- <Possible follow-ups>
- Re: Solaris /usr/bin/mailx exploit (SPARC) Tobias J. Kreidl (May 16)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Greg A. Woods (May 17)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Casper Dik (May 17)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Greg A. Woods (May 18)
- Mail delivery privileges (was: Solaris /usr/bin/mailx exploit) Wietse Venema (May 18)
- Re: Mail delivery privileges (was: Solaris /usr/bin/mailx exploit) Greg A. Woods (May 18)
- Re: Mail delivery privileges Peter W (May 19)
- Re: Mail delivery privileges Henrik Nordstrom (May 19)
- Re: Mail delivery privileges David Wagner (May 21)
- Re: Mail delivery privileges (was: Solaris /usr/bin/mailx exploit) Cy Schubert - ITSD Open Systems Group (May 19)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Greg A. Woods (May 17)
- Re: Mail delivery privileges (was: Solaris /usr/bin/mailx exploit) Olaf Kirch (May 18)
- Re: Mail delivery privileges (was: Solaris /usr/bin/mailx exploit) Dan Stromberg (May 19)
- Re: Solaris /usr/bin/mailx exploit (SPARC) Johann Klasek (May 15)