Assorted IRIX WWW vulnerabilities

Date: Fri, 16 May 1997 19:17:37 -0500
From: Yuri Volobuev <volobuev@T1.CHEM.UMN.EDU>
To: BUGTRAQ@NETSPACE.ORG
Subject: Irix and WWW

Howdy,

When I first got an Indy couple years ago, I was kinda delighted with that
fuzzy WWW stuff that was installed there.  It looked nicely.  Now I decided
to check out WWW stuff installed on a 6.2, with different intentions, and,
not surprisingly, there's an ugly side to all this.

There's an important gap that WWW bridges, that of local and remote access.
I'm pretty much sure that many people were reading about those numerous Irix
root exploits thinking "OK, what's the big deal.  All those exploits are
local.  All users on my box are nice people.  And I'm behind a firewall.
What do I care".  Well, read on. Just remember, what I'll be talking about
is not by any means a complete list of vulnerabilities, it's just a sampler.

First of all, there's webdist.cgi.  I was pretty much horrified when I found
it.  I didn't even post it and waited patiently for CERT to release an
advisory.  Curiously, in this case it was SGI who jumped the gun and
released their advisory before CERT one hit the stands, not me :).
Obviously, it was equivalent to posting an exploit.  webdist.cgi is a long
awaited implementation of a perfect bug: remote vulnerability, easy to
exploit, isn't blocked by a firewall, no traces are left (access_log is
owned by nobody).  With a wide variety of root holes present in Irix, it's
pretty much equivalent to remote root access.  Cute, isn't it?  I knew SGI
was capable of something like that, and they lived up to my best
expectations.

webdist.cgi has brothers.  cgi-bin/wrap, as J.A. Gutierrez kindly pointed
out (actually he provoked me to look at all this), can be used to list any
directory on the system.  The script itself is capable of doing even more
damage, but it's saved by the fact that it uses ARGV[0], and httpd escapes
all metacharacters in ARGV.  Script attempts to do some security checks, but
the only one that actually prevents it from being exploited is the test for
file existence.  See notes on tardist below.

wrap is designed to work in tandem with /cgi-bin/handler, which could be
used to download any file under htdocs.  That probably doesn't sound too
bad, but it is.  When users are added using Irix GUI, a symlink from
/var/www/htdocs to ~luser/public_html is created.  Now, many users like
playing with CGI scripts, which are enabled for everybody in default Irix
httpd config.  Exploiting unknown CGI script is a tedious task and requires
some vivid imagination.  handler can simplify that.  You just download the
.cgi file and look at it.  Or may be web man has protected some directory by
index.html and/or .htaccess.  wrap+handler will happily ignore all of them
and allow you to grab what you want (.htpasswd, for instance).  See example
below.  Note, that it's actually a FEATURE, not a bug, just use the script
the way it was designed to work.

Apart from nice scripts in /cgi-bin, there's a load of goods in /WhatsNew.
It's just an amazing pile of crap.  Thanks Lord it's protected by .htaccess
which only allows access from localhost, otherwise it's just a remote root
hole right there.  It has 32 (!!!) CGI scripts, and as if it wasn't enough,
there're two root-suid binaries that do most of the work, plus a root
crontab entry (every time I find a security hole in Irix, I wonder if it can
get any worse, and each time it does).  Mike Neuman's right, there's no need
to be smart here.  Both day5datacopier and day5notifier are written in a
genuine SGI root-suid style, i.e. both execute external programs while
euid=0 using system() _without_ using absolute path.  day5datacopier calls
cp first, day5notifier calls ps.  Put necessary programs with right names
first in PATH and enjoy.  "It doesn't get any better that this, dude" (tm).

The presence of .htaccess saves the day, but it's not very safe either.
Apart from various ways to circumvent it by all kinds of spoofing, it's easy
to disable it by misconfiguring httpd, like I once did.  We used to run NCSA
httpd 1.4 (the one Irix has), and one day I decided to upgrade to Apache.  I
don't remember if I decided to keep config files or replaced them, but I
didn't do anything stupid, yet .htaccess files stopped functioning.
Apparently there was no AllowOverride in config file to allow .htaccess
override access guidelines in access.conf.  May be I did something stupid,
but still it wasn't too obvious that I disabled .htaccess.  On Irix it can
mean some major backups restore.  Also, I just don't feel good about
protection mechanisms based on some file's presence.  If that file goes
away, or gets truncated, access is granted.  Of course, files are not
supposed to just go away, but sometimes they just do.

These days it's fashionable to abuse MSIE by feeding all kinds of crap to
non-suspecting surfers.  SGI is not far behind here, in fact it's ahead.
Default Irix config has Netscape, which comes with _rich_ mailcap file.
Several entries deserve honorable mentions there, but perhaps
application/x-tardist one is the best.  When poor surfer clicks on the link
that feeds that MIME type to Netscape, per mailcap it invokes
/usr/sbin/tardist on it.  tardist file is just a tar file that contains a
distribution in Irix "dist" format.  So tardist creates a subdirectory in
/tmp, untars tmp file supplied by netscape, and runs swmgr.  Now I'm an evil
guy.  I have that link on my page, disguised by javascript, that is actually
a CGI script that checks Agent header for SGI-"enhanced" netscape.  If it's
there, it fingers host where request is coming from, look at idle time and
ttys to find out which luser runs netscape and what is is home directory,
and send reply on application/x-tardist type that consists of a tar file
that contains ../../usr/people/luser/.rhosts.  Luser, after clicking on that
link, suddenly sees a window prompting for a root password (it's swmgr
running).  Luser quickly clicks Cancel, but it's too late.  tar file was
already unpacked, and luser has no idea what's happened.  Of course,
there're many ways to use this, for instance, create directory
/var/www/htdocs/blah;/tmp/myscript and /tmp/myscript, and then check out
http://victim/cgi-bin/wrap/blah;/tmp/myscript (yes, /var/www/htdocs is
world-writable).  /usr/local/lib/netscape/mailcap on Irix is loaded with
crap.  Luckily most of the entries use programs that don't exist on the box
I use, but what I can see there gives me shivers.

Sure, having booby traps on one's web page is lame, but, as it was
wonderfully said in "12 monkeys", "This woman is my psychiatrist. ..." fill
the gap yourself.

Remedies.

I think I made it clear that SGI's approach to bringing the wonders of WWW
to the desktop near you has few side effects.  My suggestions is: nuke it
all.  There's nothing useful there.  Uninstall all packages that contains
WWW stuff (notably outbox.sw.webdist, whatsnew.doc.whatsnew,
whatsnew.sw.whatsnew whatsnew.registration.whatsnew), see what's left in
/var/www/htdocs /var/www/cgi-bin, and uninstall it too.  Purge mailcap
ruthlessly.  Remember, _all_ WWW stuff from SGI is potentially dangerous,
don't take any chances.  And, even better, write an angry letter to SGI.

Whining section (nothing important here).

All of the above is pretty sad.  I simply don't get it.  It's year 1997 now.
Internet has been around for many years.  One would think that it's been
enough time for everyone to understand that it's a pretty hostile place.
Web security is the hottest topic of the day.  Still, in SGI land
everything's quiet.  Same buggy CGI scripts were shipped couple years ago,
and they are still there on newest O2s.  And it's not because a subtle bug
has slipped QC.  webdist hole is only subtle under one condition: if no one
ever looks at that script, and it seems to be the case here.  It's a company
policy, to put security issues below practically everything else.  SGI ship
software with horrible bugs without bothering to do _any_ QC.  It's really
something unique.  Buffer overflows are common.  Raceable tmp files are
common.  tmp file with predictable names are quickly becoming less common,
but still are found every now and then.  Now, what OSes are shipped with
root-suid binaries that do system() without absolute path?  Irix, one and
only.  It's simply amazing.  How difficult is it to have ONE guy to look
though the sources of critical programs quickly and identify bizzare things?
Using absolute path is really not a rocket science, nor is CGI programming.
Or take this CustReg suid crap.  Mike Neuman reported it to them a _year_
ago.  What happened?  Nothing.  I just can't come up with any reasonable
explanation for all that.  Yeah, right, it's a mainly hardware company, so
big guys don't give a damn about some software crap, that's not where the
profit is coming from.  "Customers are not asking for security, they are
asking for features".  Sure.  Five years ago computer security wasn't so
important.  Now, every box is on Internet, and commercials threatening with
Internet hazards are edging out tampax ones.  I just don't buy the idea that
people don't care.  More likely, SGI executives are living in the past.
Somebody should make a news story out of this or something, may be that'll
help a bit.

cheers,

yuri