|
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