Top Document: SGI security Frequently Asked Questions (FAQ) Previous Document: -6- How can I get X authorization to work? Next Document: -8- I think I've found a security hole in IRIX; whom should I notify? See reader questions & answers on this topic! - Help others by sharing your knowledge (Thanks to Yuri Volobuev <volobuev@t1.chem.umn.edu> for updating several questions in this question.) 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: - 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 - 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. - 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, and http://www.8lgm.org/advisories/[8lgm]-Advisory-1.UNIX.rdist.23-Apr-1991 and http://www.8lgm.org/advisories/[8lgm]-Advisory-26.UNIX.rdist.20-3-1996.html may not describe all of the known 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. - ftp://sgigate.sgi.com/Security/ 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. - http://www.8lgm.org/advisories/[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. - ftp://ftp.cert.org/pub/cert_advisories/ describes a security hole which is present in /usr/etc/rpc.ypupdated 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. - ftp://sgigate.sgi.com/Security/ 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. 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. - ftp://ftp.cert.org/pub/cert_advisories/CA-95:14.Telnetd_Environment_Vulnerability describes a vulnerability in telnetd which is present in IRIX before 6.2. 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. There is a related hole in login(1): it allows one to set LD_ envariables from the command line, and, if they are already present in its environment, passes them to programs which it invokes. Patches 1010, 1020 and 1143 for various versions of IRIX close the holes, as does IRIX 6.2. - ftp://sgigate.sgi.com/Security/ describes a hole in the objectserver which allows a local or remote user to become root. Patch 1052 to IRIX 5.2, 6.0 and 6.0.1, patch 1048 to IRIX 5.3 and patch 1090 to IRIX 6.1 close the hole. Note that patch 1048 (and perhaps its cousins) comes with a mediad which doesn't properly handle audio CDs, and that its successor, patch 1096 (successors to 1052 and 1090 are not yet available) breaks cformat(1M); see the admin FAQ. - ftp://sgigate.sgi.com/Security/ describes a hole in /usr/pkg/bin/pkgadjust (part of the SVR4 pkg system, in eoe2.sw.oampkg, not installed by default) which allows local users to overwrite files and execute arbitrary programs as root. To close the hole, either remove eoe2.sw.oampkg or 'chmod -s /usr/pkg/bin/pkgadjust'. If you do leave eoe2.sw.oampkg installed, note that /usr/pkg/bin/abspath is setuid root as well. This is not yet known to be a security problem, but is certainly not necessary, and the careful admin will want to 'chmod -s' it as well. Since neither program needs to be setuid, no patch is necessary. Future releases of IRIX will not install them setuid. - ftp://sgigate.sgi.com/Security/ and ftp://ftp.cert.org/pub/cert_advisories/ describe a hole in rpc.statd (see statd(1M)), present in all IRIXes before 6.2, which allows a remote user to mount denial-of-service attacks or create or remove files as root. Patch 1226 (IRIX 5.2), 1128 (6.0 and 6.0.1) and 1391 (5.3) close the hole. There is no patch for IRIX 6.1. The hole is fixed in IRIX 6.2. - The xdm(1) manpage(!) describes a bug in IRIX 5.x (at least) which allows a user to connect to a local display even when X authorization should prevent one from doing so. (Fortunately, this doesn't work for remote displays.) Close the hole with patch 1075, or just turn off shared memory transport by adding the option '-shmnumclients 0' to the X command in /usr/lib/X11/xdm/Xservers. See also the lengthy discussion of X authorization above and the description of the putative X authorization weaknesses below. - LicenseManager 2.0 (a prerequisite for some of the free software on Silicon Surf) a) allows any user to manipulate licenses and, b) when one adds a new license, may delete old, unrelated licenses. The problem is fixed in LM 2.0.1. Also, LicenseManager 1.x through 3.0 have bugs in them which can allow any user to become root. 'chmod -s /usr/etc/LicenseManager' will close them; however, this will preclude any user other than root from using LicenseManager to manipulate licenses. - ftp://info.cert.org/pub/cert_advisories/ describes a bug which allows remote users to run commands as root on a pcnfsd server. The bug is present in the version of pcnfsd which SGI provides for IRIX 5.3, but not in that for IRIX 6.2 (or other IRIX 6.x?). It is fixed by patch 1179 for IRIX 5.3. - /usr/bin/rmail has a bug which allows a local user to assume the permissions of group mail, and thus (most importantly) read anyone's mail. It is fixed in patch 1273 for IRIX 5.2-6.1 and 1281 for 6.2. - ftp://sgigate.sgi.com/Security/ and ftp://sgigate.sgi.com/Security/ describe holes in the desktop administration tools which allow users to change permissions on and edit files which they do not own. They are closed by patches 1519, 1518, 1517 and 1516 for IRIX 5.2, 5.3, 6.1 and 6.2 respectively. - /usr/bin/X11/cdplayer and /usr/sbin/datman (also known as 'cdman') have security holes in them that can allow users to execute arbitrary programs as root. At this time, SGI has not released patches for these programs yet, so the way to close the hole is via 'chmod -s /usr/bin/X11/cdplayer /usr/sbin/datman'. This will unfortunately prevent non-root users from using cdman, datman, and cdplayer; other Motif-based CD players are available on the Internet which may not share cdplayer's vulnerabilities. These problems are described in more detail in AUSCERT advisories ftp://ftp.auscert.org.au/pub/auscert/advisory/AA-96.11.SGI.cdplayer.vul and ftp://ftp.auscert.org.au/pub/auscert/advisory/AA-96.20.SGI.datman.cdman.vul - /var/rfindd/fsdump has a security hole in it which allows users to overwrite arbitrary files and (in so doing) gain root access. 'chmod -s /var/rfindd/fsdump' will close the hole and also disable rfindd. - /sbin/suid_exec, a component of ksh that assists ksh in running setuid shell scripts, has a security hole in it that allows users to execute arbitrary programs as root. 'chmod -s /sbin/suid_exec' will close the hole and also prevent ksh from executing setuid shell scripts. (Execution of setuid shell scripts is off by default on most releases of IRIX anyway.) - /usr/Cadmin/bin/csetup, the "EZsetup" system setup manager, has a security hole in it that allows users to execute arbitrary programs as root. - ftp://sgigate.sgi.com/security/ describes a vulnerability in /usr/lib/print/netprint, which allows any local user to become root. Apply following patch 1685 (for 5.3/6.1) or 2022 (for 6.2). 5.2 doesn't have netprint. Note, that this patch may break printing. To fix it, add this to the top of /etc/init.d/lp TMPDIR=/var/tmp export TMPDIR HOME=/var/spool/lp export HOME LOGNAME=lp export LOGNAME then run "/etc/init.d/lp stop ; /etc/init.d/lp start" These bugs have not yet been fixed: - /usr/bin/lp has several bugs that allow any local user to gain lp privileges. If you don't need its functionality, consider removing the suid bit from lp. If you do need it, you can "wrap" the lp binary with a wrapper that cleans up critical environment variables (e.g. PATH), checks the command line for shell metacharacters and length limits. - The default root crontab contains a call to /usr/etc/fsr. By default, under certain conditions it can be used to obtain root privileges. Edit root's crontab and add "-f /var/adm/.fsrlast" option to the fsr command line. - /usr/etc/cvpcsd is part of the CaseVision WorkShop package. It's invoked by inetd with root priviledges. It has a vulnerability that allows any root priviledges. It has a vulnerability that allows any local user to overwrite any file on the system, and, under certain conditions, become root. Check your /etc/inetd.conf for this or a similar line: sgi_pcsd/1 dgram rpc/udp wait root ?/usr/etc/cvpcsd pcsd -L if it's there, consider commenting it out. (Don't forget to 'killall -HUP inetd' after you've commented it out.) - /usr/lib/InPerson/inpview, part of the InPerson desktop conferencing tool, has a vulnerability that allows any local user to become root. If you don't need InPerson functionality, remove the suid bit from inpview (with 'chmod u-s /usr/lib/InPerson/inpview'). If you do need it, restrict execution privileges to the trusted group of individuals that have access to the console. - /usr/bin/startmidi that comes with the standard IRIX 5.3 distribution has a vulnerability that allows any local user to become root. However, startmidi that comes with Desktop Special Edition 1.1 is not vulnerable to this problem. IRIX 6.2 doesn't seem to be vulnerable either. Check your machine by running "showfiles | grep startmidi". If your output is: f 64563 18688 dmedia_eoe.sw.midi usr/sbin/startmidi your machine is most likely not vulnerable to this problem. If you see f 46022 18608 dmedia_eoe.sw.midi usr/sbin/startmidi your system is probably vulnerable, so remove the suid bit from startmidi (with 'chmod u-s /usr/sbin/startmidi'). If it's neither of the above, remove the suid bit just to be safe. There's no official advisory or workaround for this problem. - /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. - /usr/Cadmin/bin/csetup, the "EZsetup" system setup manager, has a security hole in it that allows users to execute arbitrary programs as root. 'chmod -s /usr/Cadmin/bin/csetup' will close the hole but prevent non-root users from running csetup. This bug is present in IRIX 5.3 and probably in later versions as well. - 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 (although a cursory search of the man page xwsh(1) does not reveal how to do so). 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. - 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 1146 prevents sendmail from passing dangerous data to syslog(3) in the first place, which prevents exploitation of the hole via sendmail only. - /usr/lib/X11/app-defaults/ISDN, the X resources file for the ISDN confidence test module which is part of at least some versions of SGI's ISDN software (details welcome), is both executable and setuid root. 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. This will be fixed in IRIX 6.2. - http://www.stardot.net/~hhui/SDN-advisories/SDN-2-sgi-videoframer a) describes a hole in the VideoFramer development software which allows a local user to overwrite files, and b) points out that VF includes many setuid scripts, which are a well-known Unix security problem (although not in the default IRIX configuration). Fix both problems with 'chmod -s /usr/video/vfr/*'. - /usr/gfx/setmon has holes (present at least in IRIX 5.3) which allow a local user to read files which should be readable only by root and to crash the machine. 'chmod -s' it. (Thanks to Hui-Hui Hu <hhui@stardot.net>.) - /usr/etc/uncompvm in IRIXes up to 5.3 and 6.1 is setgid sys. It doesn't need to be (crash dumps are readable only by root, not by group sys) so 'chmod -s' it. It will not be setgid sys in IRIX 6.2. (Thanks to Hui-Hui Hu <hhui@stardot.net>.) - par(1) will display data read by a setuid program, even if the program would not itself have printed that data. One can thus use par and a suitably leaky setuid program (known examples include arp(1M), setmon(1G) and uncompvm(1M)) to read files for which one would otherwise not have permission. This will be fixed by a patch to IRIX 5.3 and in IRIX 6.2. - ftp://ftp.cert.org/pub/cert_advisories/ describes a bug in expreserve which allows any user to overwrite any file on the system. ftp://sgigate.sgi.com/Security/ explains that since SGI's expreserve is setgid sys rather than setuid root as on some othere systems (yay SGI!), it can only overwrite files which can be written by group sys. Since there are no important files which can be written by group sys, no patch is planned. The bug will be fixed in a future release. Make sure that there are, indeed, no important files on your system which are writable by group sys. If you don't need expreserve, 'chmod -s' it. The following advisories describe holes whose presence in IRIX we can't confirm or deny at present: http://www.8lgm.org/advisories/[8lgm]-Advisory-12.UNIX.suid_exec.27-Jul-1991 ftp://ftp.cert.org/pub/cert_advisories/ ftp://ftp.cert.org/pub/cert_bulletins/ ftp://ftp.cert.org/pub/cert_advisories/ User Contributions:Top Document: SGI security Frequently Asked Questions (FAQ) Previous Document: -6- How can I get X authorization to work? Next Document: -8- I think I've found a security hole in IRIX; whom should I notify? Single Page [ Usenet FAQs | Web FAQs | Documents | RFC Index ] Send corrections/additions to the FAQ Maintainer: sgi-faq@viz.tamu.edu (The SGI FAQ group)
Last Update March 27 2014 @ 02:12 PM
|
Comment about this article, ask questions, or add new information about this topic: