[20721] in bugtraq
Re: Mail delivery privileges (was: Solaris /usr/bin/mailx exploit)
daemon@ATHENA.MIT.EDU (Greg A. Woods)
Sat May 19 19:10:28 2001
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: woods@weird.com (Greg A. Woods)
To: "Steven M. Bellovin" <smb@research.att.com>
Cc: wietse@porcupine.org (Wietse Venema), bugtraq@securityfocus.com
In-Reply-To: <20010519010434.5D6A27B84@berkshire.research.att.com>
Reply-To: woods@weird.com (Greg A. Woods)
Message-Id: <20010519021656.E3966C3@proven.weird.com>
Date: Fri, 18 May 2001 22:16:56 -0400 (EDT)
[ On Friday, May 18, 2001 at 21:04:33 (-0400), Steven M. Bellovin wrote: ]
> Subject: Re: Mail delivery privileges (was: Solaris /usr/bin/mailx exploit)
>
> That's more an artifact of Plan 9 than of upas -- upas on Unix did
> support 'Pipe to'. But Plan 9 has no notion of setuid nor (as I
> recall) of superuser, so it can't do that.
Of course.... (you remember correctly, there's no super-user in Plan 9
-- the user who boots a workstation, and thus logs in first, is
essentially it's privileged user and owns most devices and can control
all processes)
BTW, I have found reference now to what I was thinking of in SysVr4.
It's mail_pipe(1M), and indeed:
mail_pipe is installed as a privileged process thus
enabling itself to change it's user and group ids to that
of the recipient as necessary.
This is from 4.2, and I may have been thinking of 4.0, though even there
it may have been setuid-root too and I can no longer check.
> And while there are
> certainly security issues with delivery to programs (that's why
> sendmail had to implement smrsh), not having write ability to per-user
> files causes problems for programs like 'vacation'.
I have in the past implemented a "central" vacation facility that used a
single shared database to keep track of which addresses it had sent
replies to on a per-user basis. Such applications do require a central
system facility and this obviously doesn't solve the more general
problem.
There is another obvious trick too -- the user can install his own
setuid program such that when the LDA invokes it the user's privileges
are taken on. Obviously there are many problems with this trick, but it
does avoid the need to make the LDA run as root. ;-)
--
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>
