A bunch of IRIX holes found by Yuri Volubuev

Date: Wed, 7 May 1997 05:48:00 -0500
From: Yuri Volobuev <volobuev@T1.CHEM.UMN.EDU>
To: BUGTRAQ@NETSPACE.ORG
Subject: Irix: misc

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.