[16157] in bugtraq
Re: sperl 5.00503 (and newer ;) exploit
daemon@ATHENA.MIT.EDU (Greg A. Woods)
Wed Aug 9 16:56:45 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000808182703.2E96787@proven.weird.com>
Date: Tue, 8 Aug 2000 14:27:03 -0400
Reply-To: "Greg A. Woods" <woods@weird.com>
From: "Greg A. Woods" <woods@WEIRD.COM>
X-To: "Francis J. Lacoste" <francis.lacoste@INSU.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <398F06C0.D63BEC48@iNsu.COM>
[ On Monday, August 7, 2000 at 14:58:08 (-0400), Francis J. Lacoste wrote: ]
> Subject: Re: sperl 5.00503 (and newer ;) exploit
>
>
> Regarding the suidperl / mailx security problem, here are
> two patches which closes the hole in perl and in mailx.
>
> The perl bug is closed by using syslog rather than /bin/mail
>
> The mailx patch (against 8.1.1 + redhat/debian patches) does
> the following :
>
> - Do not lookup options in the environment.
> - Do not read rc files when running with uid != euid
> - Unset interactive when sending mail with uid != euid
> or when stdin is not a tty.
I've been rather dismayed by the number of people posting patches which
claim to "fix" mailx, aka BSD Mail. One could contend that it's not
even broken in the first place!
This mail user agent, like almost all others except perhaps the original
V7 /bin/mail (which is the only version of '/bin/mail' Perl was no doubt
expecting to use!), was never really designed to be used safely by root,
either for sending or reading e-mail, and it most certainly was not
designed to be used for sending e-mail safely from a privileged
application! Now I've probably been guilty of doing all of the above at
one time or another, but that doesn't mean it is safe to do!
While patches such as these which have been proposed address the
currently discovered "features", those of us who remember playing with
restricted shells on commercial Unixes in days gone by will also know
that this is probably far from the only way a privileged application
could be fooled into giving away its privileges should it be foolish
enough to call upon something like mailx.
While the ultimate error may be in the fallacy of having a setuid script
interpreter, the mistake in this particular instance falls upon the
linux vendors who chose to offer a /bin/mail that radically changed the
assumptions an application like perl could be safe in making.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
