COMMAND
/var/rfindd/fsdump
SYSTEMS AFFECTED
IRIX 5.x, 6.0, 6.0.1, 6.1, 6.2
PROBLEM
The fsdump program is found in the eoe.sw.rfindd and
eoe2.sw.rfindd subsystems which are not installed by default.
As optional subsystems, these packages must be explicitly
installed for use. Only systems with the fsdump program present
are vulnerable.
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, there are other means of
hacking a system, but we just like .rhosts 'cos it's the easiest
and we are lazy today). 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.
SOLUTION
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 who would bet on it).