[16113] in bugtraq
Re: sperl 5.00503 (and newer ;) exploit
daemon@ATHENA.MIT.EDU (Kyle Sparger)
Mon Aug 7 13:50:16 2000
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-2100098259-965654266=:5593"
Message-ID: <Pine.LNX.4.10.10008070826010.5593-200000@vaevictis.local.dialtoneinternet.net>
Date: Mon, 7 Aug 2000 09:17:46 -0400
Reply-To: Kyle Sparger <ksparger@DIALTONEINTERNET.NET>
From: Kyle Sparger <ksparger@DIALTONEINTERNET.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.LNX.4.21.0008051825300.26685-101000@dione.ids.pl>
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
--8323328-2100098259-965654266=:5593
Content-Type: TEXT/PLAIN; charset=US-ASCII
> 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. <=-----=
>
--8323328-2100098259-965654266=:5593
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="perl5.005_03-mail.patch"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.10008070917450.5593@vaevictis.local.dialtoneinternet.net>
Content-Description:
Content-Disposition: attachment; filename="perl5.005_03-mail.patch"
LS0tIHBlcmw1LjAwNV8wMy9wZXJsLmMJU2F0IE1hciAyNyAxMjo0OToxNyAx
OTk5DQorKysgcGVybDUuMDA1XzAzL3BlcmwuYy5maXhlZC1tYWlsCU1vbiBB
dWcgIDcgMDg6MzU6MDAgMjAwMA0KQEAgLTIyMjAsMTYgKzIyMjAsNiBAQA0K
IAkgICAgaWYgKHRtcHN0YXRidWYuc3RfZGV2ICE9IFBMX3N0YXRidWYuc3Rf
ZGV2IHx8DQogCQl0bXBzdGF0YnVmLnN0X2lubyAhPSBQTF9zdGF0YnVmLnN0
X2lubykgew0KIAkJKHZvaWQpUGVybElPX2Nsb3NlKFBMX3JzZnApOw0KLQkJ
aWYgKFBMX3JzZnAgPSBQZXJsUHJvY19wb3BlbigiL2Jpbi9tYWlsIHJvb3Qi
LCJ3IikpIHsJLyogaGVoLCBoZWggKi8NCi0JCSAgICBQZXJsSU9fcHJpbnRm
KFBMX3JzZnAsDQotIlVzZXIgJWxkIHRyaWVkIHRvIHJ1biBkZXYgJWxkIGlu
byAlbGQgaW4gcGxhY2Ugb2YgZGV2ICVsZCBpbm8gJWxkIVxuXA0KLShGaWxl
bmFtZSBvZiBzZXQtaWQgc2NyaXB0IHdhcyAlcywgdWlkICVsZCBnaWQgJWxk
LilcblxuU2luY2VyZWx5LFxucGVybFxuIiwNCi0JCQkobG9uZylQTF91aWQs
KGxvbmcpdG1wc3RhdGJ1Zi5zdF9kZXYsIChsb25nKXRtcHN0YXRidWYuc3Rf
aW5vLA0KLQkJCShsb25nKVBMX3N0YXRidWYuc3RfZGV2LCAobG9uZylQTF9z
dGF0YnVmLnN0X2lubywNCi0JCQlTdlBWWChHdlNWKFBMX2N1cmNvcC0+Y29w
X2ZpbGVndikpLA0KLQkJCShsb25nKVBMX3N0YXRidWYuc3RfdWlkLCAobG9u
ZylQTF9zdGF0YnVmLnN0X2dpZCk7DQotCQkgICAgKHZvaWQpUGVybFByb2Nf
cGNsb3NlKFBMX3JzZnApOw0KLQkJfQ0KIAkJY3JvYWsoIlBlcm1pc3Npb24g
ZGVuaWVkXG4iKTsNCiAJICAgIH0NCiAJICAgIGlmICgNCg==
--8323328-2100098259-965654266=:5593--
