Re: sperl 5.00503 (and newer ;) exploit

[Paul Rogers <paul.rogers () MIS-CDS COM>]

Hi,

Due to an oversight on my part, I failed to mention that /home (in fact all
non-root writable filesystems) are mounted nosuid so wouldn't allow an
ordinary user to execute the exploit.

This brings me on to a different subject entirely - I'm looking at writing a
whitepaper on securing a Linux system through analysing the needs of the
system, auditing the filesystem (suid/sgid/o+w/silly permissions), removing
unwanted binaries, ensuring that only essential services are running,
setting up ipchains to start protecting your box, ids, machine state
checking tools, security through obscurity, groups and "acls", protecting
the system from users, etc.... I could go on for pages about what ideas I
have had already.

The logic behind writing something like this is to incorporate the workable
and respected tools that are available along with sample configuration files
for these tools and the operating system. A number of papers brush on
certain issues and possible configuration recommendations but I would like
to drill down and breakdown into more detail. I would also like to include
some sample "case-studies" into the paper to give users and/or new admins an
example guide of implementing a secure system.

Firstly, would you or the arena be interested in such a wide ranging paper
and secondly have you got any ideas that you would like to see in it?

I know this isn't this forum to discuss this, so please e-mail me
personally, otherwise this won't get posted :-)

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: Paul Rogers [mailto:paul.rogers () MIS-CDS COM]
> Sent: 07 August 2000 10:29
> To: VULN-DEV () SECURITYFOCUS COM
> Subject: Re: sperl 5.00503 (and newer ;) exploit
>
>
> 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.
> **********************************************************************