Workaround sementara hingga ada yg lebih baik:
chmod 0 /usr/bin/suidperl
Ronny
----- Forwarded message from Michal Zalewski <[EMAIL PROTECTED]> -----
> From: Michal Zalewski <[EMAIL PROTECTED]>
> Reply-To: Michal Zalewski <[EMAIL PROTECTED]>
> Date: Sat, 5 Aug 2000 18:39:22 +0200
> To: [EMAIL PROTECTED]
> 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 <[EMAIL PROTECTED]>
> # Tested with sperl 5.00503, but should work with any other as well.
> #
> # Good luck and don't abuse it.
> #
>
> _______________________________________________________
> Michal Zalewski [[EMAIL PROTECTED]] [tp.internet/security]
> [http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
> =-----=> God is real, unless declared integer. <=-----=
----- End forwarded message -----
----- Forwarded message from Michal Zalewski <[EMAIL PROTECTED]> -----
> From: Michal Zalewski <[EMAIL PROTECTED]>
> Reply-To: Michal Zalewski <[EMAIL PROTECTED]>
> Date: Sat, 5 Aug 2000 19:19:36 +0200
> To: [EMAIL PROTECTED]
> Subject: Re: sperl 5.00503 (and newer ;) exploit
>
> 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 <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
>
> 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 [[EMAIL PROTECTED]] [tp.internet/security]
> [http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
> =-----=> God is real, unless declared integer. <=-----=
>
>
----- End forwarded message -----
--------------------------------------------------------------------------
Utk berhenti langganan, kirim email ke [EMAIL PROTECTED]
Informasi arsip di http://www.linux.or.id/milis.php3
Pengelola dapat dihubungi lewat [EMAIL PROTECTED]
