Home page logo
/

bugtraq logo Bugtraq mailing list archives

Irix: more suid fun/exploits
From: volobuev () t1 chem umn edu (Yuri Volobuev)
Date: Thu, 28 Nov 1996 05:55:38 -0600


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



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]