Bugtraq mailing list archives
Irix: misc
From: volobuev () T1 CHEM UMN EDU (Yuri Volobuev)
Date: Wed, 7 May 1997 05:48:00 -0500
Howdy, This spring's been quiet so far, as long as Unix bugs and Bugtraq are concerned. People seem to concentrate on Windoze more these days. Or may be after years of hacking most Unices finally started to run out of bugs. Well, Irix is certainly not one of them, it seems like one who looks shall always find something. I for myself haven't been looking all that much recently, because lots of things were going on, among other stuff I changed my job, so system administration is no longer one of my direct duties, I'm more of a (malicious) luser now. So I don't get to mess with Irix as much as I used to. However, back in good old days, I've found few bugs, which I didn't post, for various reasons, mainly because most of them were not very serious, or I wanted to do some studying before posting. Anyway, now that I've retired I think I'd better share this with Bugtraq community while I still remember it. Unfortunately, I don't have root access to 5.3 anymore, so some descriptions may be not totally accurate where it comes to 5.3, I apologize for that. 1. /usr/lib/InPerson/inpview inpview is part of InPerson desktop video conferencing package. It's root-owned/suid and is written in a classic SGI suid-programming style, i.e. in the course of execution inpview, without dropping euid=0, starts program ttsession, using system() and without bothering to use absolute path. So it's pretty much like suid shell sitting around, in case you forget root password. It does all kinds of other dangerous stuff as well, e.g. predictable tmp files. Obvious fix is to strip suid bit, which is most likely to break it. I don't know why it's necessary to be root to establish non-authentificated connection between two machines, but I guess SGI guys know better. If you do need InPerson badly, consider restricting execution privileges to the trusted group of users, or putting a standard wrapper around it, kind of what AUSCERT usually supplies with their advisories. Such a wrapper should reset critical environment variables (PATH, HOME, LOGNAME, etc.), check command line for unwanted characters (shell metacharacters, see sh(1) manpage), checks command line and may be few environment variables for length. It doesn't protect you from all evils, notably nothing can be done about tmp files, but it's better than nothing. 2. /usr/bin/lp It's a pretty bad one. I reported it to SGI/CERT/AUSCERT back in Dec'96, but so far everything's quiet. It allows anyone to get lp priorities. Because /usr/etc/lpd is suid (why? it shouldn't be, at least on Linux it's not, and it's the same BSD-derived one), it can be further leveraged all the way to root. Even if you wisely strip suid bit off lpd, it doesn't help a lot, hacker can still steal identities of people who print. Vulnerability is basically equal to netprint hole, which was found patch-worthy by SGI. I'm not going in details, because I still have faint hope that SGI is going to release a patch for it. Immediate solution may be a wrapper, as outlined above. A much better long-term solution would be to dump all Irix printing stuff and install LPRng instead, it emulates both lpr/lpq and lp/lpstat. See ftp://dickory.sdsu.edu/pub/LPRng/ for details. 3. root crontab Though suid programs are the most common source of exploits, there're other places to look. root's crontab on Irix contains various items. For example, it has several entries that do recursive find+rm. The dangers of this were discussed on Bugtraq a while back. As far as I remember, it allows to remove arbitrary files on the system by exploiting race condition in find in connection with symlinks. Also, cron runs /usr/etc/fsr weekly on Sun morning. fsr is disk defragmentation tool, it writes positions where it left off to file /usr/tmp/.fsrlast. It's merely a DOS threat because of the contents of the file, I can't see any easy way to get root out of it. Fix is simple: edit root's crontab and add -f /var/adm/.fsrlast option to fsr. This problem is not particularly dangerous because /usr/tmp is never cleaned up, so .fsrlast, once written, will stay there forever, effectively preventing people from replacing it with symlink. But on brand new boxes it may cause bad things. Some interesting results may be obtained by feeding properly constructed .fsrlast to fsr, but I didn't look closely at it. 4. /usr/tmp/.syserr.data I'm not particularly sure about this one. Default /etc/syslog.conf filters syslog messages through /usr/sbin/sysmonpp, which invokes /usr/sbin/syserr, which writes info about particularly bad errors (e.g. logical swap space exhausted) to file /usr/tmp/.syserr.data. File contents is clear text, and it can be used to get root by overwriting some binary that suid program executes (e.g. sgihelp, see my previous post about csetup exploit for an example). Again, the file is probably never removed, so danger is only present on new machines. Touch this file to make sure no one messes around with it. SGI once released a patch for sysmonpp, I seem to remember, but I can't find that advisory or patch on their web site anymore, it was probably incorporated in some other patch, which may not be installed on the box I'm using. As far as I remember, that advisory characterized the bug as "highly obscure", and its exploitation required "intimate knowledge of the system", so this little problem doesn't seem to qualify. 5. /usr/etc/cvpcsd cvpcsd is part of WorkShop debugger suit. It's present in /etc/inetd.conf where it's started as root. It unconditionally writes log file /usr/tmp/cvpcsd.log. Fortunately, it does chmod 444 on it, i.e. it's only readable, not executable, so getting root out of it would be fairly difficult, barring .rhosts+DNS spoofing. I didn't find any easy way to modify it's contents in a usable way, it would require writing a specialized client (cvconect can be used to communicate with cvpcsd), and I'm way too lazy for that. Still it's a decent DOS. Another good thing about this problem is that file actually contains some information about who was connecting to cvpcsd. So touch it and keep an eye on it. 6. xfsdump xfsdump would write log file to /usr/tmp/bck.log, unasked for, which may allow to get root. Touch it. 7. rmail This one is ridiculous. /usr/bin/rmail is sgid mail. Man page clearly says rmail is only required by UUCP, still, it's installed everywhere. It's also been known to have bugs for years, which SGI has addressed by a series of patches. Quite unfortunately, all of them fail to fix the problem completely, including the most recent one, 1639 (for 6.2, it has brothers for other releases). It's a small and simple program, it just passes slightly modified message from stdin to sendmail, as usually via virtue of system(). Why it takes several shots to fix it, I just don't understand. To exploit, set LOGNAME env to something like blah;mycommand. Fortunately, it syslogs all invocations of itself, so at least you'll know when someone is doing something bad. Remove sgid bit from it. That's all I can recall now. There's a separate issue regarding Irix and WWW, I'll post my thoughts on it some time soon. Irix is standing alone among other mainstream Unices in a sense that no buffer overflow exploits are publically available. Of course, Irix compensates this shortcoming by posting big numbers in other columns, it's way ahead of the pack as far as non-overflow bugs are concerned, but still, it's something that bothers me. It's not that there's a theoretical problem with buffer overruns on Irix, it's just have not been done publically. Somebody may be exploiting it actively for years now. I did some work on it few months back, taking an opportunity to learn MIPS assembly. It wasn't difficult to write shell code, but getting rid of zero bytes appeared to be trickier. Essentially it requires constructing of an instruction on the fly. I got shell code that works on R3000, but it won't work on any newer CPU, presumably because of cache coherency problem of some sort. So I either need a way to defeat that, or write some code that searches for necessary instructions in available data space (which may work, but is ugly so I'm reluctant to do it). Anyway, if somebody with some MIPS assembly expertise wants to help out, we can share our experiences. Terra incognita of Irix buffer overflow exploits is waiting. Last note. There's a fairly decent SGI security FAQ at http://www-viz.tamu.edu/~sgi-faq/faq/html/security/. It's not completely up-to-date, but otherwise is OK. I sent FAQ maintainers my suggestions recently, which may help them to get it in sync with current events. I think eventually they'll update it. Sending FAQ maintainers mails could speed up the process. I hope to keep on cooperating with them, so that this FAQ could save some lost sysadmin souls. cheers, yuri P.S. Bugtraq had 6000 subscribers back in Jan, and it's 10K now. That's some growth rate. Congrats, Aleph and all.
Current thread:
- Irix: misc Yuri Volobuev (May 07)
- Re: Irix: misc J.A. Gutierrez (May 08)
- Re: Irix: misc Jaechul Choe (May 08)
- SGI Security Advisory 19961203-02-PX - IRIX netprint Program SGI Security Coordinator (May 08)
- Bug Serious problem in NEC SOCKS server Trevor Schroeder (May 09)
- Re: Bug Serious problem in NEC SOCKS server Matt Bush (May 09)
- Windows 95/NT DoS myst (May 09)
- More buffer overrun crap -- Solaris 2.5.1 /usr/bin/ps Joe Zbiciak (May 10)
- Re: More buffer overrun crap -- Solaris 2.5.1 /usr/bin/ps kevin brintnall (May 10)
- Re: Windows 95/NT DoS Albert Siersema (May 10)
- Re: Windows 95/NT DoS DiGennaro (May 10)