Irix: another root exploit
Yuri Volobuev (volobuev@t1.chem.umn.edu)
Thu, 21 Nov 1996 13:41:16 -0600
Howdy,
Brand new root exploit for Irix. This one's a _little_ less lame than the
previous one, this time it's more like trading 10 years old's dad's truck
for a really cool bicycle.
Abstract
/usr/bin/X11/cdplayer, part of a standard Irix 5.3/6.2 installation, is
suid and insecure. It can be used by any local user for creating
root-owned, world-writable arbitrarily named directory anywhere on the
system. Some other weaknesses of standard Irix configuration allow to
convert it to root priviledges.
How to fix:
chmod -s /usr/bin/X11/cdplayer
(it will break it, but it's no big deal, there's a program called cdman,
usually invoked by double-clicking CD ROM icon on the desktop, that does the
same thing, only better, and it's not suid).
To make your Irix generally more safe:
systune -i
restricted_chown 1
then answer y and press Enter. 5.3 requires reboot for the change to take
effect, I'm not sure about 6.2.
In /etc/passwd replace line
sysadm:*:0:0:System V Administration:/usr/admin:/bin/sh
with something like
sysadm:*:0:0:System V Administration:/:/bin/nono
or, if you know what you are doing, just remove it. Removing it _might_
break something.
If you are busy person, move on to your next message now. If you think you
have some time and patience, read on.
Exploiting suid program vulnerability: practical example.
=========================================================
The world of Unix vulnerabilities is big, and suid programs present a good
part of it. Irix is no exception. How can this be exploited?
Let's review the situation on example. Look in /usr/bin/X11. There are
several suid programs, but most of them are standard to all Unices, so their
holes are well known and thus are not interesting for research purposes.
One binary caught our eye -- cdplayer. It's Irix special, must be
interesting. Close look reveals that indeed it is.
Suid program that does file I/O always has something to offer. First step,
reading man page, shows that it stores CD catalogs and programs in ~/.cddb
directory. Well, let's see it working. Put audio CD in the drive, run
cdplayer. Looks nice. Let's make a short CD description and look at what
we have on the disk. Indeed, ~/.cddb is there, but it's empty. Hm. ls -ld
~/.cddb. Owned by root? Interesting. But harmless. What is the use of
root-owned ~/.cddb? But what did that man page say about CDDB_WRITE_PATH?
Yep, RTFMing always helps, now we have .cddb in /etc. Let's see if catalog
files themselves are root-owned. Nope. And it refuses to overwrite anything.
Too bad, it's suid-aware and gives up root priorities. So it's still
useless. But it begins to look promising so we take standard step #2,
strings /usr/bin/X11/cdplayer
As usually, out friend strings tells us many interesting facts. For
example, there are few strings that look like command line options,
particularly -dbcdir. Yep, these are valid options, though not documented
in man page. What -dbcdir does? Suddenly, our abilities increase from
creating .cddb anywhere to creating a root-owned arbitrarily named directory
anywhere. Not bad. But how empty directory could be usefull? No way. And
it's writable only by root... hm. Suddenlly, friend Jay drops by and asks
what's up. Explain him our advances so far. Jay isn't so much of a hacker,
but he's curious anyway. What permissions that directory has, he asks?
Really, let's take a look. drwxr-xr-x -- why so? Wait a moment, what is
our umask? Bull's eye. umask 000; cdplayer -dbcdir /etc/test. drwxrwxrwx.
Cool. Well, yeah, but what now? We can write whatever we want to an
arbitrary directory in arbitrary place -- if it doesn't exist already.
Sounds pretty useless. Well, it's time to take a little break, relax, chat,
enjoy some spare time. Rested, we continue. We were we? Uhu. Some
thinking reveals that indeed all that we have earned so far is pretty
useless -- on an ideal OS. But we deal with Irix, which is pretty far from
this nice state and more close to opposite, user-friendly OS.
Some scientists say that humans only use fraction of their brain, the rest
is there but isn't being used. What is true about humans is usually true
about things that humans create, in particular /etc/passwd files. Lets take
a peek. Right near the top, we see an interesting line
sysadm:*:0:0:System V Administration:/usr/admin:/bin/sh
wow. uid 0. But it's starred out. And home directory doesn't exist.
DOESN'T EXIST? He he. One call to our friend cdplayer, and it does. Now
what? .forward? Doesn't work, sysadm is in /etc/aliases. More chatting
with Jay, and suddenly it strikes me -- why I'm so stupid? Why I first
think about .forward, not about obvious things?
echo "+ +" >/usr/admin/.rhosts
As fingers type, lips are telling Jay that it's not going to work.
Yep, it doesn't, .rhosts have to be owned by the home directory owner, i.e.
sysadm. But we're almost there. Last effort -- recall it's Irix, and it's
user-friendly. Remember, some time ago somebody on bugtraq (or was it
linux-security?) asked what is bad in giving away your own file. Well,
here's a live demo
chown root.sys /usr/admin/.rhosts
rsh localhost -l sysadm
and we enjoy that wonderful, sweet, warm feeling every hacker gets when he
sees # as his command prompt. When the machine is friend's, where he
doesn't have root access, which is the case. Not anymore.
So what's the moral of that long lousy story? Few seemingly minor problems:
cdplayer gives up root priorities a little too late, unused account with uid
0 in passwd, chown not restricted in default kernel config -- small pieces
make a big picture. The moral is that cdplayer shouldn't be suid -- why
cdman isn't and still it works? sysadm account shouldn't be there and
shouldn't have real shell for sure, chown should be restricted by default.
But the way it is, a standard Irix 5.3/6.2 installation is vulnerable.
Sorry to be so talkative, I'm procrustinating. My only alternative is
written exam.
cheers,
yuri
always speaking for myself and only for myself