Major holes in IRIX IPX tools

Description:Sigh, IRIX was trivial to root before, but now thanks to their IPX tools it is even easier. We are talking blatant system() calls here! The story in this message is rather pathetic.
Author:Fabrice Planchon <fabrice@MATH.PRINCETON.EDU>
Compromise: root (local)
Vulnerable Systems:IRIX 6.3, perhaps earlier versions.
Date:8 April 1998

Date: Wed, 8 Apr 1998 18:48:55 -0400
From: Fabrice Planchon <fabrice@MATH.PRINCETON.EDU>
Subject: SGI O2 ipx security issue

Hi all,
SGI O2 running Irix 6.3 come with support for the IPX protocol from
Novell. This stuff is installed by default, and live in
among other things, there are 2 suid binaries, ipxchk and ipxlink. None
of them are documented anywhere, and they allow root access in the most
simple way (think IFS=/). So, if you don't use ipx, I recommend to just
chmod u-s both of them. (see below if you have a support contract)

Now, the full story: I reported this bug to SGI in june 97, providing a
clear explanation on how and why it appeared to be a *really* bad idea
to have the 2 binaries suid. They weren't resetting the environment,
were calling other programs via system, messing with temp files, in
short everything which shouldn't be done. I was assured by SGI that a
security fix would be released within 2 months, and by the end of the
summer, I asked via the support line what was the status, and was
answered that the patch was soon to be officially released, and that
they could give it to me if I wanted to. I therefore dowloaded the
patch, which was patchSG0001693, intended to be released as a
security-fix patch (and therefore, freely available). 5 minutes after
installing the patch, I was root again. The patch (sorry, for some
reason I erased it inadvertantly) was doing 2 things: changing the
permissions to rws--x--x, and hardcoding IFS and the path of various
binaries called. In short, they did a very poor job, even if I had taken
extra steps to explain everything to them after being asked to be more
specific after the initial bug report. Anyway, I immediatly reported
that the problem was not fixed at all, and they didn't release the patch
publically. Since then I never heard from SGI again. I want to take the
opportunity to thank AUSCERT for being responsive on that subject, and
for trying to help. A couple of weeks ago, I was looking for other
patches and noticed Patch_SG0002869. From the release notes:

   This patch contains fixes for the following bugs in IRIX 6.3
       O2 R10K.  Bug numbers from Silicon Graphics bug tracking
       system are included for reference.

          o 498565 - ipxchk and ipxlink have security issues

It should be noted that
-this patch is *not* a security patch (it contains other fixes)
-it is not even a freely available patch, you need a valid support
contract to get it, and it's not in the recommended set of patches
-the way the bug is fixed is by removing ipxchk and having ipxlink no
longer suid. (I asked why it was suid in the first place, but never got
an answer)

So, anyway, I just thought I would share my experience. It was said that
SGI has improved on security issues, and it is true so far that they
have taken steps to fix things like buffer overflows lately, but it
looks like this little story tells us that we cannot trust any vendor on
the subject of security. To think that in a modern OS released in 96 you
find something exploitable with tricks from the 80's is scary.


#!/usr/local/bin/perl --    -export-a-crypto-system-sig -RSA-3-lines-PERL
print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>

More Exploits!

The master index of all exploits is available here (Very large file)
Or you can pick your favorite operating system:
All OS's Linux Solaris/SunOS Micro$oft
*BSD Macintosh AIX IRIX
ULTRIX/Digital UNIX HP/UX SCO Remote exploits

This page is part of Fyodor's exploit world. For a free program to automate scanning your network for vulnerable hosts and services, check out my network mapping tool, nmap. Or try these Insecure.Org resources: