Up: SGI security Frequently Asked Questions (FAQ)
Next: -8- I think I've found a security hole in IRIX; whom do I notify at SGI?
Previous: -6- How can I get X authorization to work?
Subject: -7- What security-related bugs does IRIX have?
Date: 28 Nov 1995 00:00:01 EST
Some general comments before we start:
- IRIX is too complex for us to guarantee that this list is complete.
We only discuss problems we know about. We don't discuss insecurely
designed systems (like YP) or ways in which you might misconfigure
your system, only bugs. We don't discuss third-party software,
free or not.
- Prudence and space permit us to describe only how to close holes,
not to exploit them. Try comp.security.unix.
- Some of the fixes involve installing a new version of a setuid
binary. Be sure that you 1) make it executable, setuid and owned
by the correct user and group (or it won't work), and 2) remove the
old version so bad guys can't use it!
Now for the holes themselves, in approximate order of closure:
- CERT advisory CA-92:08, which you can get from
ftp://ftp.cert.org/pub/cert_advisories/CA-92:08.SGI.lp.vulnerability
describes problems with the permissions of 'lp'-related parts of
IRIX which allow anyone who can log in as lp to get root access.
They are fixed in IRIX 4.0.5. Briefly, the fix is
su root
cd /usr/lib
chmod a-s,go-w lpshut lpmove accept reject lpadmin
chmod go-ws lpsched vadmin/serial_ports vadmin/users vadmin/disks
cd /usr/bin
chmod a-s,go-w disable enable
chmod go-ws cancel lp lpstat
- CERT advisory CA-93:17, which you can get from
ftp://ftp.cert.org/pub/cert_advisories/CA-93:17.xterm.logging.vulnerability
describes a hole in /usr/bin/X11/xterm which allows any user root
access. It is fixed in IRIX 5.x. A fixed version for 4.x is at
ftp://ftp.sgi.com/sgi/IRIX4.0/xterm/
The 'fix', incidentally, is that logging is completely disabled.
- /usr/bin/under is an unused (!) part of 'rexd'. It is setuid root
and may allow root access, so 'chmod -s' it just in case. Note that
SGI ships IRIX with 'rexd' turned off because 'rexd' is itself a
security problem. It is not shipped in IRIX 5.x.
- CIAC Bulletin F-01, which you can get from
ftp://ciac.llnl.gov/pub/ciac/bulletin/f-fy95/f-01.ciac-SGI-IRIX-serial-ports
describes a race condition in IRIX 4.0.x's
/usr/lib/vadmin/serial_ports which allows any user to become root
in IRIX 4.0.x. 'chmod 700' it to close the hole; it will still work
fine.
/usr/lib/vadmin/serial_ports is part of IRIX 4.0.x and should not
exist on IRIX 5.x systems, but some users have reported problems
with upgrading from 4.0.x to 5.x which leave old binaries behind.
If the file exists on your 5.x system, remove it. (5.x's
equivalent, /usr/Cadmin/bin/cports, does not have the problem.)
- /usr/bsd/rdist has several holes which allow any user root access in
all versions of IRIX before 5.3, including the 4.0.5 and 5.x
binaries on ftp.sgi.com.
Under IRIX 5.2, you can install patch 130 to close all known
holes. Under IRIX 4.0.x, you must close the hole with 'chmod -s'.
rdist will then work only when used by root. If your non-root users
need 'rdist', there is a free version, which does not need to be
setuid root and is thus free of all known holes, in
ftp://usc.edu/pub/rdist/. Make sure you get version 6.1 beta 3 or
later. IRIX 5.3's rdist is derived from this version and is thus
equally safe; presumably ordist is the IRIX 5.2-patch 130 rdist and
is also safe.
As for advisories, CERT advisory CA-91:20, at
ftp://ftp.cert.org/pub/cert_advisories/CA-91:20.rdist.vulnerability
is badly out of date. 8lgm advisory 1, at
ftp://ftp.tansu.com.au/pub/docs/security/8lgm/8lgm-Advisory-1.UNIX.rdist.23-Apr-1991
describes only one of the several holes.
- The 'lpr' subsystem in every version of IRIX before 5.3 has several
holes which allow a non-root user to become root. Note that 'lp' is
SGI's usual printing system; you only need 'lpr' if you need to deal
with remote printers. If you don't need 'lpr', make sure it isn't
installed. (It lives in the eoe2.sw.lpr subsystem.) If you do need
'lpr', there are fixed versions at
ftp://ftp.sgi.com/sgi/IRIX4.0/lpr/lpr.latest.Z
ftp://ftp.sgi.com/sgi/IRIX5.0/lpr/lpr.latest.Z
The versions dated 29 and 26 April, respectively, work with NIS
(YP). The IRIX 5.x version is also available as patch 131.
- /usr/sbin/cdinstmgr is setuid root in IRIX 4.0.5[A-F] and
/etc/init.d/audio is setuid root in IRIX 5.2. They are scripts;
setuid scripts are a well-known Unix security problem. IRIX ignores
the setuid bit by default, but 'chmod -s' the scripts just in case.
- SGI advisory 19950209-01-P, which you can get from
ftp://sgigate.sgi.com/Security/19950209-01-P
describes a bug in colorview in IRIX 5.x before 5.3, which allows
anyone to use it to read any file regardless of permissions, and
gives a fix.
- /usr/bin/newgrp is group-writable in IRIX 5.2. It doesn't need to
be, and it might be a problem depending on your use of group sys
and/or the presence of the 'sadc' bug (described elsewhere in this
list) on your system. 'chmod g-w' it.
- /usr/sbin/printers has a bug in IRIX 5.2 (and possibly earlier 5.x
versions) which allows any user to become root. Apply patch 5. You
might want to 'chmod -s' it while you're waiting.
- /usr/sbin/sgihelp has a bug in IRIX 5.2 (and possibly earlier 5.x
versions) which allows any user to become root. This is so bad that
the patch (#65, along with the prerequisite patch 34) is FTPable
from ftp://ftp.sgi.com/security/, and SGI is preparing a CD
containing only that patch. Call the TAC if you can't FTP. You
should 'chmod -x /usr/sbin/sgihelp' while you're waiting.
- The inst which comes with patch 34 (for IRIX 5.2), which is required
for installation of all other patches (even those with lower
numbers) saves old versions of binaries in /var/inst/patchbase. It
does not remove execution or setuid permissions! 'chmod 700' that
directory so evil users can't get to the old binaries. The bug is
fixed in patch 82 for IRIX 5.2 and in IRIX 5.3.
- 8lgm advisory 11, which you can get from
ftp://ftp.tansu.com.au/pub/docs/security/8lgm/8lgm-Advisory-11.UNIX.sadc.07-Jan-1992
describes a hole in the System V system activity reporting program
/usr/lib/sa/sadc which allows any user to write files with the
permissions of that program. This bug is present in all versions of
IRIX through 5.3, but since /usr/lib/sa/sadc is only setgid sys it
can only be used to change groups sys-writable files or write files
in group sys-writable directories. If you don't use the system
activity reporter you might want to 'chmod -s /usr/lib/sa/sadc' just
to be safe. Because this hole isn't serious it isn't scheduled to be
closed, but write permission for group sys has been removed from
most directories where it wasn't necessary in IRIX 5.3, and a few
more (/dev/*dsk) will be fixed in a later release.
- /usr/etc/mount_dos, IRIX's DOS-filesystem floppy mounter, has a
serious bug in IRIX 5.2 (and probably earlier releases of 5.x as
well) which allows anyone with an account on and physical access to
a machine with a floppy drive root access. This bug can be fixed
with patch 167 and is reportedly fixed in IRIX 5.3. Perhaps the
easiest interim "fix" (which essentially disables all removable
media drives) is to disable mediad: "mediad -k" kills the current
instance of mediad, and "chkconfig mediad off" prevents mediad from
starting during the next reboot.
- /usr/etc/rpc.ypupdated may have a security hole in all versions of
IRIX. It is completely unnecessary in most networks; the only
instance that we could think of that might require this daemon would
be NIS networks that include Sun diskless clients. You should
probably comment it out of /etc/inetd.conf, or just not install the
nfs.sw.nis subsystem, of which it is a part. It is commented out by
default in IRIX 5.3.
- SGI advisory 19950301-01-P373, which you can get from
ftp://sgigate.sgi.com/Security/19950301-01-P373
describes a bug in /usr/lib/desktop/permissions in IRIX 5.2, 6.0 and
6.0.1 which allows any user to change the permissions of any file to
anything. (Click on "Apply" twice fast, then click "Cancel" to
dismiss the root password window.) It is fixed in patch 373 for IRIX
5.2, 6.0 and 6.0.1 and in IRIX 5.3. Until you patch or upgrade,
'chmod -s' it to close the hole.
- sendmail is a complex program in which new security holes are
discovered almost daily. Some of these holes enable unprivileged
users (and in one case even *remote* users!) to gain root access.
The safest course of action seems to be to use the most recent
sendmail possible. All known holes are closed in the sendmail which
comes with patch 825. (Note that SGI advisory 19950201-02-P332, at
ftp://sgigate.sgi.com/Security/19950201-02-P332, is out of date.
Note also that the sendmail.cf.auto which comes with patch 825 does
not work at some sites, but the original sendmail.cf.auto from IRIX
5.3 works fine with the sendmail binary from patch 825.)
Recent sendmail patches also fix a bug present in every IRIX
sendmail before 5.3: /usr/bsd/newaliases (which is just a symlink to
/usr/lib/sendmail) creates /etc/aliases.{dir,pag} with mode 666. Any
user can thus add aliases which can run programs or steal mail.
Close the hole with 'chmod go-w /etc/aliases.dir /etc/aliases.pag'.
sendmail doesn't change those files' permissions once they exist, so
a) you should check them even if you've installed a sendmail in
which the problem is fixed and b) once they exist and have proper
permissions, you're OK.
- /usr/etc/arp has a hole in IRIX 5.2 and earlier which allows any
user to read files with 'arp's permissions, i.e. group sys. Close
the hole with 'chmod -s'. This prevents non-root users from using
'arp' at all, but they don't generally need it. The hole is closed
in IRIX 5.3.
- SoftWindows 1.25 (which is distributed by SGI in Desktop Support
Environment 1.0 and HotMix 11) includes an installation script which
executes Netscape as root. This can be used to gain root access,
etc. Patch 905 (if your Softwindows is installed as the
"SoftWindows" subsystem) or 908 (if it's in the "swin" subsystem)
fixes the script.
- CERT advisory CA-95:14, at
ftp://ftp.cert.org/pub/cert_advisories/CA-95:14.Telnetd_Environment_Vulnerability
describes a vulnerability in telnetd in (among other OSes) all
current versions of IRIX. A remote user can use telnet/telnetd to
pass environment variables to login which cause login to use an
arbitrary shared library. If the same user can place a shared
library on the system running telnetd (e.g. by depositing it in an
incoming FTP directory), that user can gain root permissions.
Patches 1010 for IRIX 6.1 and 1020 for IRIX 5.x and 6.0.x close the
hole. They also close a related hole in login(1): the fixed login
does not allow one to set LD_ envariables from the command line,
and, if they are already present in its environment, does not pass
them to programs which it invokes.
These bugs have not been fixed, as far as we know, in any IRIX version
or patch so far:
- /usr/lib/so_locations.old can acquire random permissions after an
'inst' session in IRIX 5.3, due to a linker bug. It may become both
executable and setuid and/or setgid. It is not a script but could be
used as one; setuid scripts are a well-known Unix security problem.
IRIX ignores the setuid bit by default, but 'chmod -xs' it just in
case. The linker bug should be fixed in IRIX 6.2.
- 8lgm advisory 12, which you can get from
ftp://ftp.tansu.com.au/pub/docs/security/8lgm/8lgm-Advisory-12.UNIX.suid_exec.27-Jul-1991
describes a bug in /etc/suid_exec (part of ksh) which allows any
user to become root. This bug is probably *not* present in any
version of IRIX (says Dave Olson <olson@sgi.com>), but if you don't
use setuid ksh scripts you might want to 'chmod -s /etc/suid_exec'
just to be safe.
- 'xdm' has a bug in IRIX 5.x (at least) which allows a user to
connect to a local display even when X authority should prevent one
from doing so. (Fortunately, this doesn't work for remote displays.)
Close the hole by turning off shared memory transport by adding the
option '-shmnumclients 0' to the X command in
/usr/lib/X11/xdm/Xservers. See the xdm(1) manpage for the original
report of this hole! See also the lengthy discussion of other
problems with X authorization above.
- xwsh recognizes escape sequences which remap keys. An evildoer
can place escape sequences in a file or filename which, when passed
to xwsh to be displayed, remap keys to unexpected strings or to
xwsh internal functions. The escape sequences are not displayed and
may not be detected by the victim.
Programs which can pass these escape sequences to xwsh include
'cat', 'more', /bin/mail and /usr/bsd/Mail, and other programs such
as mail and news agents which call these programs to display text.
Programs which display filenames, such as 'ls' and 'find', can pass
escape sequences in filenames to xwsh.
Programs which do not recognize the remapping sequences, such as
xterm and MediaMail, and programs which remove escape sequences
from displayed text or replace them with safe characters, such as
'ls' with the '-b' or '-q' option, 'more' with the '-r' option, the
'less' pager and the Elm mailer's built-in pager, are safe.
This vulnerability is inherent in the ANSI standard escape codes
which xwsh respects; any terminal or terminal emulator which
recognizes these sequences has this problem. Recognition of these
escape codes ought to be optional, e.g. controlled by an X
resource. It will be in IRIX 6.2. No patch is planned for earlier
versions of IRIX.
The safest workaround is to use xterm instead of xwsh. The next best
is to run only safe programs and/or display only safe text in xwsh
windows. If you use xwsh, alias 'ls' to 'ls -b' and 'more' to 'more
-r'. You could alias 'cat' to 'cat -v', or (to avoid corrupting
files when using 'cat' in pipelines) train yourself not use 'cat' to
display files.
- CERT advisory CA-95:13, at
ftp://ftp.cert.org/pub/cert_advisories/CA-95:13.syslog.vul
describes a problem with the syslog(3) system call in which data
passed to syslog(3) can corrupt the stack and cause execution of
arbitrary code. If a program will accept data from an untrusted
(even remote) user and pass it to syslog(3) without bounds checking,
a *very* clever user can usurp the permissions of that program.
The hole will be closed in IRIX 6.2. There are no patches for
current versions of IRIX, and none are planned, because SGI finds it
difficult to distribute an installable patch to libc.so (where
syslog(3) lives). However, patch 825 prevents sendmail from passing
dangerous data to syslog(3) in the first place, which prevents
exploitation of the hole via sendmail only.
Up: SGI security Frequently Asked Questions (FAQ)
Next: -8- I think I've found a security hole in IRIX; whom do I notify at SGI?
Previous: -6- How can I get X authorization to work?