Bugtraq mailing list archives
Irix and WWW
From: volobuev () T1 CHEM UMN EDU (Yuri Volobuev)
Date: Fri, 16 May 1997 19:17:37 -0500
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
Current thread:
- Irix and WWW Yuri Volobuev (May 16)
- SunOS exploit. Trevor Linton (May 18)
- Re: SunOS exploit. Christopher X. Candreva (May 19)
- Re: SunOS exploit. Austin Schutz (May 19)
- Re: SunOS exploit. Daniel Reish (May 20)
- Re: SunOS exploit. Christopher X. Candreva (May 19)
- Re: Irix and WWW James Bonfield (May 19)
- Re: Irix and WWW Bill Paul (May 19)
- SunOS exploit. Trevor Linton (May 18)