home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / sgi / faq / security < prev   
Encoding:
Text File  |  2001-07-06  |  48.7 KB  |  1,005 lines

  1. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!micro-heart-of-gold.mit.edu!nntp.club.cc.cmu.edu!usenet01.sei.cmu.edu!hammer.uoregon.edu!enews.sgi.com!news.tamu.edu!sgi-faq
  2. From: sgi-faq@viz.tamu.edu (The SGI FAQ group)
  3. Newsgroups: comp.sys.sgi.misc,comp.answers,news.answers
  4. Subject: SGI security Frequently Asked Questions (FAQ)
  5. Supersedes: <security_993016817@viz.tamu.edu>
  6. Followup-To: comp.sys.sgi.misc
  7. Date: 6 Jul 2001 05:59:50 GMT
  8. Organization: Visualization Lab, Texas A&M University
  9. Lines: 986
  10. Approved: news-answers-request@mit.edu
  11. Expires: 3 Aug 2001 06:00:15 GMT
  12. Message-ID: <security_994399215@viz.tamu.edu>
  13. Reply-To: sgi-faq@viz.tamu.edu (The SGI FAQ group)
  14. NNTP-Posting-Host: viz.tamu.edu
  15. NNTP-Posting-Date: 6 Jul 2001 05:59:50 GMT
  16. Originator: sgi-faq@viz.tamu.edu
  17. Xref: senator-bedfellow.mit.edu comp.sys.sgi.misc:57362 comp.answers:46107 news.answers:210659
  18.  
  19. Archive-name: sgi/faq/security
  20. Last-modified: Sat Jan  6  1:00:03 CST 2001
  21. Posting-Frequency: Twice monthly
  22. URL: http://www-viz.tamu.edu/~sgi-faq/
  23.  
  24.     SGI security Frequently Asked Questions (FAQ)
  25.  
  26. This is one of the Silicon Graphics FAQ series, which consists of:
  27.  
  28.     SGI admin FAQ - IRIX system administration
  29.     SGI apps FAQ - Applications and miscellaneous programming
  30.     SGI audio FAQ - Audio applications and programming
  31.     SGI diffs FAQ - Changes to the other FAQs since the last posting
  32.     SGI graphics FAQ - Graphics and user environment customization
  33.     SGI hardware FAQ - Hardware
  34.     SGI impressario FAQ - IRIS Impressario
  35.     SGI inventor FAQ - IRIS Inventor
  36.     SGI misc FAQ - Introduction & miscellaneous information
  37.     SGI movie FAQ - Movies
  38.     SGI performer FAQ - IRIS Performer
  39.     SGI pointer FAQ - Pointer to the other FAQs
  40.     SGI security FAQ - IRIX security
  41.  
  42. Read the misc FAQ for information about the FAQs themselves. Each FAQ is
  43. posted to comp.sys.sgi.misc and to the news.answers and comp.answers
  44. newsgroups (whose purpose is to store FAQs) twice per month. If you
  45. can't find one of the FAQs with your news program, you can get it from
  46.  
  47.     ftp://viz.tamu.edu/pub/sgi/faq/
  48.     ftp://rtfm.mit.edu/pub/usenet/news.answers/sgi/faq/
  49.  
  50. (rtfm.mit.edu is home to many other FAQs and informational documents,
  51. and is a good place to look if you can't find an answer here.) The FAQs
  52. are on the World Wide Web at
  53.  
  54.     http://www-viz.tamu.edu/~sgi-faq/
  55.  
  56. If you can't use FTP or WWW, send mail to mail-server@rtfm.mit.edu with
  57. the word 'help' on a line by itself in the text, and it will send you a
  58. document describing how to get files from rtfm.mit.edu by mail. Send the
  59. command 'send usenet/news.answers/sgi/faq/misc' to get the SGI misc FAQ,
  60. and similarly for the other FAQs. Send the command 'send
  61. usenet/news.answers/internet-services/access-via-email' to get the
  62. "Accessing the Internet by E-Mail FAQ".
  63.  
  64. You may distribute the SGI FAQs freely and we encourage you to do so.
  65. However, you must keep them intact, including headers and this notice,
  66. and you must not charge for or profit from them. Contact us for other
  67. arrangements. We can't be responsible for copies of the SGI FAQs at
  68. sites which we do not control, and copies published on paper or CD-ROM
  69. are certain to be out of date. The contents are accurate as far as we
  70. know, but the usual disclaimers apply. Send additions and changes to
  71. sgi-faq@viz.tamu.edu.
  72.  
  73. Topics covered in this FAQ:
  74. ---------------------------
  75.    -1- Where can I learn about IRIX and Unix security?
  76.    -2- How can I check my system for security problems?
  77.    -3- How can I configure IRIX to be more secure?
  78.    -4- How can I log more information about logins?
  79.    -5- How can I make an anonymous or restricted FTP account?
  80.    -6- How can I get X authorization to work?
  81.    -7- What security-related bugs does IRIX have?
  82.    -8- I think I've found a security hole in IRIX; whom should I notify?
  83.    -9- How can I get around the root and/or PROM passwords?
  84.   -10- What firewalls are available on SGI/IRIX platforms?
  85.  
  86. ----------------------------------------------------------------------
  87.  
  88. Subject:    -1- Where can I learn about IRIX and Unix security?
  89. Date: Thu Dec  7 17:14:28 CST 2000
  90.  
  91.   IRIX: Look in ftp://sgigate.sgi.com/Security/ and at
  92.   http://www.sgi.com/support/security/index.html for SGI security
  93.   advisories and patches.  SGI also runs a mailing list called
  94.   "wiretap" for dissemination of IRIX security advisories from SGI;
  95.   its subscription address is <wiretap-request@sgi.com>.  An article in 
  96.   the Jul/Aug 1994 Pipeline discusses general Unix security with some
  97.   IRIX-specific aspects.
  98.  
  99.   Unix in general: Look in ftp://ftp.cert.org/,
  100.   ftp://ciac.llnl.gov/pub/ciac/ and http://www.8lgm.org/ for CERT, CIAC
  101.   and 8lgm material (respectively) and general security information and
  102.   tools.  If you have a lot of spare time, consider the
  103.   comp.security.unix newsgroup and/or the bugtraq mailing list 
  104.   (listproc@netspace.org, archived at http://www.securityfocus.com/)
  105.  
  106. ------------------------------
  107.  
  108. Subject:    -2- How can I check my system for security problems?
  109. Date: 04 May 1996 00:00:01 EST
  110.  
  111.   Get Nate Sammons <nate@vis.colostate.edu>' 'rscan' (formerly
  112.   'securscan') from ftp://ftp.vis.colostate.edu/pub/rscan/ (and see its
  113.   documentation etc. at http://www.vis.colostate.edu/rscan/). It checks
  114.   for many bugs and problems, both specific to IRIX and generic to Unix.
  115.   Unfortunately, it has not been updated since April 1995 and will not
  116.   detect most holes discovered since then. You might also want to try a
  117.   generic Unix security-checking tool such as COPS, tiger or SATAN
  118.   and/or a password checker such as Crack. SGI's security page
  119.   referenced above gives their locations.
  120.  
  121. ------------------------------
  122.  
  123. Subject:    -3- How can I configure IRIX to be more secure?
  124. Date: 30 Mar 1996 00:00:01 EST
  125.  
  126.   Several aspects of SGI's default IRIX configuration were chosen for
  127.   convenience, not security. Unless your machine is not networked, you
  128.   may be more concerned about security than SGI assumed.  Note that
  129.   these items have been discussed on Usenet many times, and Usenet
  130.   chatter is not a good way to change SGI policy. If they bother you,
  131.   complain to your sales rep and then fix them yourself as follows.
  132.  
  133.   Under any version of IRIX,
  134.  
  135.   - Several accounts come without passwords, including (but not limited
  136.     to) guest, 4Dgifts, demos, tutor, tour and particularly lp. Examine
  137.     /etc/passwd and lock all unnecessarily open accounts.  Note that 1)
  138.     parts of IRIX (e.g. 'inst') use the open guest account by default,
  139.     and 2) remote 'lp' clients need access to the lp account to print,
  140.     so you'll need to make other arrangements. Completists may wish to
  141.     read CERT advisory CA-95:15, at
  142.     ftp://info.cert.org/pub/cert_advisories/CA-95%3A15.SGI.lp.vul, and
  143.     SGI advisory 19951002-01-I, at
  144.     ftp://sgigate.sgi.com/Security/19951002-01-I.
  145.  
  146.   - 'xdm' does 'xhost +' by default when you log in. This allows anyone
  147.     to open windows on your display and even to record what you type at
  148.     your keyboard. Close this hole by removing the 'xhost +' from
  149.     /usr/lib/X11/xdm/Xsession, /usr/lib/X11/xdm/Xsession-remote and (in
  150.     IRIX 5.x) /usr/lib/X11/xdm/Xsession.dt. In IRIX 5.2 and later you
  151.     can use X authorization to control access to remote displays; see
  152.     below. In IRIX 5.1.x and earlier X authorization doesn't work, so
  153.     you'll need to use 'xhost' judiciously to get to remote displays:
  154.     say 'xhost +localhost' to run DGL programs and 'xhost +otherhost' to
  155.     display remote X programs.
  156.  
  157.   - At least some of the possible default values of the PATH
  158.     environment variable begin with the current directory. (The system
  159.     interprets either a period or the empty string in any component of
  160.     PATH as the current directory. PATH is colon-separated, so if it
  161.     begins with a colon the first component is the empty string.) This
  162.     exposes you to Trojan horse programs. Set PATH to a safe value
  163.     (remove the current directory, or at least move it to the end) in
  164.     /etc/cshrc and/or /etc/profile for regular users and /.login for
  165.     root.
  166.  
  167.   - By default, /etc/config/ypbind.options contains the -ypsetme
  168.     option. This allows someone who can fake your IP address to change
  169.     your YP binding. Remove the -ypsetme option to close the hole and
  170.     add the -s option for a little extra protection. Comment out the
  171.     invocations of 'ypset' in /var/yp/make.script and /var/yp/ypmake to
  172.     avoid error messages.  If your site runs ypbind with the -v
  173.     (verbose) option, you may also want to add 'YPSET=true' to
  174.     /etc/config/ypmaster.options and comment out the 'ypset' line in
  175.     /var/yp/ypmake. See the ypbind(1) and ypset(1) manpages for more.
  176.  
  177.   - If you use SLIP (see slip(1M)), be sure that SLIP accounts' home
  178.     directories are not world-writable. SLIP accounts are uid 0, so
  179.     it's bad if just anyone can mess with their .forward files and the
  180.     like.  /tmp, which is recommended in the "IRIX Advanced Site and
  181.     Server Administration Guide", is necessarily world-writable and a
  182.     bad choice.  You may want to make an empty, root-owned, mode 755
  183.     directory to the effect of /usr/slip and use that. Any number of
  184.     SLIP accounts can use a single home directory without conflict.
  185.  
  186.   - Add '-a' to the rlogind and rshd lines in /etc/inetd.conf to require
  187.     remote hostnames and addresses to match.  You *might* want to
  188.     disallow .rhosts files by adding the '-l' flag as well, but this
  189.     removes real functionality and should not be done without reason.
  190.     See the rlogind(1M) and rshd(1M) manpages.  Note that rlogind's '-l'
  191.     flag does not work in IRIX 5.2. It does work in IRIX 5.3.
  192.  
  193.   - The default root crontab in current IRIXes
  194.     (/var/spool/cron/crontabs/root) creates the SYSLOG and cron log with
  195.     group and world read permission. Change the '033' on lines 25 and 27
  196.     to '077' to prevent non-superusers from reading these files.
  197.  
  198.   - By default, xdm looks for X terminal login requests on port
  199.     177. This is no different (for security purposes) than allowing
  200.     rlogin or telnet connections, but it might be undesirable in some
  201.     environments. Edit /var/X11/xdm/Xaccess to restrict this access,
  202.     e.g. by placing a `!' in front of each of the two lines which begin
  203.     with an asterisk to prevent all XDMCP requests.
  204.  
  205.   - /etc/init.d/rmtmpfiles resets the permissions on /tmp and /var/tmp
  206.     at every bootup. By default, permissions are set to 1777; the '1'
  207.     means sticky, so one user can't remove another's temporary files. If
  208.     one does 'chkconfig nostickytmp on', permissions are set to 777 and
  209.     any user can remove another's temporary files. Don't do this: it
  210.     allows a variety of attacks involving race conditions in setuid
  211.     programs. A related class of attacks is described in
  212.     ftp://ciac.llnl.gov/pub/ciac/bulletin/f-27.permissions-on-tmp.asc,
  213.     but note that Sun's tmpfs is not an essential component of the hole.
  214.  
  215.   - Non-root users can give away files. This can be used to defeat
  216.     accounting and quotas. Set the 'restricted_chown' kernel variable to
  217.     1 to allow only root to give away files. This may break some
  218.     programs which depend on unrestricted chown, e.g. /bin/mail (when
  219.     delivering to an NFS volume without root access) as discussed in the
  220.     admin FAQ. (Thanks to Jonathan Rozes <jrozes@tufts.edu> for this and
  221.     the next item.)
  222.  
  223.   - NFS connections to unprivileged ports are accepted by default. Set
  224.     the 'nfs_portmon' kernel variable to 1 to reject NFS connections
  225.     to unprivileged ports.
  226.  
  227.   - /etc/inetd.conf enables some unnecessary services. The 'echo'
  228.     and 'chargen' services can allow a denial-of-service attack, as
  229.     described, for example, in CERT advisory CA-96.01, at
  230.     ftp://ftp.cert.org/pub/cert_advisories/CA-96.01.UDP_service_denial.
  231.     To disable those particular services, comment out the lines which
  232.     begin with their names in /etc/inetd.conf and 'killall -HUP inetd'.
  233.     You may want to disable other unused UDP-based services as well.
  234.  
  235.   - Many devices have permissions which might allow a user to monitor
  236.     another user via audio or video input, including
  237.  
  238.     /dev/audio
  239.     /dev/dmrb
  240.     /dev/hdsp/*
  241.     /dev/vid
  242.     /dev/video
  243.  
  244.     Bill Paul <wpaul@ctr.columbia.edu>'s solution is to add the
  245.     following to /usr/lib/X11/xdm/Xstartup
  246.  
  247.     chmod 600 /dev/audio /dev/hdsp/* /dev/video /dev/vid /dev/dmrb
  248.     chown $USER /dev/audio /dev/hdsp/* /dev/video /dev/vid /dev/dmrb
  249.  
  250.     and the following to /usr/lib/X11/xdm/Xreset
  251.  
  252.     chmod 600 /dev/audio /dev/hdsp/* /dev/video /dev/vid /dev/dmrb
  253.     chown root /dev/audio /dev/hdsp/* /dev/video /dev/vid /dev/dmrb
  254.  
  255.     (Simon ? <simon@instrumatic.ch> pointed out that the chmod should
  256.     precede the chown to avoid a race condition.)
  257.  
  258.   - Read the rest of the entries in this section and make the changes
  259.     they describe if appropriate.
  260.  
  261.   Under IRIX 5.x or later only,
  262.  
  263.   - Turn on shadow passwords, which are not used by default. Run
  264.     'pwconv' to move your passwords to /etc/shadow, where only root can
  265.     read them. Note that you'll have to update /etc/shadow by hand for
  266.     NIS users. See the pwconv(1M) and shadow(4) manpages.
  267.  
  268.   - Limit the hosts from which portmap(1M) and rpcbind(1M) will accept
  269.     RPC requests by using the -a option in /etc/config/portmap.options.
  270.     For example, if your machine is www.xxx.yyy.zzz and your subnet is
  271.     www.xxx.yyy you can reject RPC requests from outside your subnet by
  272.     putting '-a 255.255.255.0 www.xxx.yyy.0' in that file. Despite the
  273.     file's name and the absence of any options in the rpcbind manpage,
  274.     this appears to work with rpcbind as well as portmap. Note also the
  275.     related putative bug under "security-related bugs" below.
  276.  
  277.   This list is guaranteed to be incomplete. Keep your eyes open.
  278.   Similar lists are in SGI's security advisory 19950401-01-I, which is
  279.   at ftp://sgigate.sgi.com/Security/19950401-01-I, and a post by Dave
  280.   Olson <olson@sgi.com>, a copy of which is at
  281.   ftp://viz.tamu.edu/pub/sgi/software/security/olson-security.
  282.  
  283. ------------------------------
  284.  
  285. Subject:    -4- How can I log more information about logins?
  286. Date: 27 May 1996 00:00:01 EST
  287.  
  288.   - 'last', 'who', etc. get remote login information from
  289.     /var/adm/utmpx and /var/adm/wtmp. That information is only logged
  290.     into these files if they already exist. To create them, do
  291.     'touch /var/adm/utmpx /var/adm/wtmpx'. The analogous files under
  292.     IRIX 4.0.x are /etc/xutmp and /etc/xwtmp.
  293.  
  294.   - If you're running IRIX 5.3, install patch 420 to fix a bug which
  295.     causes xterm(1) to log logins incorrectly.
  296.  
  297.   - As described in the login(1) manpage, you can add the line
  298.     'syslog=all' to /etc/config/login.options (IRIX 4.0.x) or change the
  299.     line 'SYSLOG=FAIL' in /etc/default/login to 'SYSLOG=ALL' (IRIX 5.x)
  300.     to log all login attempts, not just successful ones, in
  301.     /var/adm/SYSLOG. Under IRIX 5.x only, the same change in
  302.     /etc/default/su has the same effect on 'su' attempts.
  303.  
  304.   - 'ftpd', 'rshd', 'tftpd' and 'fingerd' all have options ('-l' or
  305.     '-L') which cause them to log all accesses. See their manpages.
  306.     'ftpd' also has '-ll' and '-lll' options (undocumented before IRIX
  307.     5.x) which log individual file transfers and the sizes of those
  308.     files respectively.  Add the options to the last fields (not the
  309.     second-to-last) of the appropriate lines of /etc/inetd.conf, then do
  310.     'killall -HUP inetd' or reboot.
  311.  
  312.   - Consider using Wietse Venema's tcp_wrappers, at
  313.     ftp://ftp.win.tue.nl/pub/security/. This allows you not only to log
  314.     most types of connections, but to restrict connections from
  315.     particular hosts and prevent some forms of address spoofing.
  316.     README.IRIX in current versions of tcp_wrappers describes a number
  317.     of ways in which it does not work well with IRIX, some of them
  318.     serious. tcp_wrappers is still useful, but read README.IRIX
  319.     carefully and test your configuration to be sure it's working.
  320.  
  321. ------------------------------
  322.  
  323. Subject:    -5- How can I make an anonymous or restricted FTP account?
  324. Date: 13 Aug 1995 00:00:01 EST
  325.  
  326.   Read the ftpd(1M) manpage and/or the article in the March/April 1994
  327.   Pipeline. However, both discussions have a serious error: the ftp
  328.   account's home directory (/usr/people/ftp) should be owned and
  329.   writable only by root, NOT ftp. You might also want to make the 'pub'
  330.   directory "sticky" with 'chmod +t' (like /tmp and /var/tmp) so that
  331.   one user can't delete another's files. Two scripts which set up a
  332.   secure or restricted anonymous FTP account are at
  333.   ftp://viz.tamu.edu/pub/sgi/software/ftp/.
  334.  
  335. ------------------------------
  336.  
  337. Subject:    -6- How can I get X authorization to work?
  338. Date: 24 Feb 1996 00:00:01 EST
  339.  
  340.   Under IRIX 5.1.x or earlier, don't try. The MIT-MAGIC-COOKIE-1
  341.   protocol did not work, and DGL programs did not understand X
  342.   authorization.
  343.  
  344.   Under IRIX 5.2, heed the wise words of Mark Kilgard of SGI's
  345.   X Window Systems group <mjk@hoot.asd.sgi.com>:
  346.  
  347.   The basic mechanism for the MIT-MAGIC-COOKIE-1 authorization protocol
  348.   is implemented by the X server, Xlib, and xdm, and does work in IRIX
  349.   5.x.  MIT-MAGIC-COOKIE-1 is the only supported protocol.
  350.  
  351.   Two caveats before I describe how to enable X authorization:
  352.  
  353.   1) Old remote IRIS GL programs probably will not be able to connect to
  354.      the X server when X authorization is enabled. (More on this below.)
  355.  
  356.   2) Due to a problem with how the local hostname is handled, to use X
  357.      authorization in the IRIX 5.x releases, you will need to make sure
  358.      your /etc/sys_id file has a simple hostname, ie. hoot instead of a
  359.      fully resolved hostname like hoot.asd.sgi.com  This problem has
  360.      already been fixed for the next general release of IRIX.
  361.  
  362.   TO ENABLE X AUTHORIZATION, do the following to your IRIX 5.2 system:
  363.  
  364.       1)  Edit /var/X11/xdm/xdm-config as root and change the line
  365.       saying
  366.  
  367.   DisplayManager*authorize:               off
  368.  
  369.         to say
  370.  
  371.   DisplayManager*authorize:               on
  372.  
  373.       2) Edit /var/X11/xdm/Xsession, /var/X11/xdm/Xsession-remote, and
  374.      /var/X11/xdm/Xsession.dt as root and change the line saying
  375.  
  376.   /usr/bin/X11/xhost +
  377.  
  378.          to say
  379.  
  380.   #/usr/bin/X11/xhost +
  381.  
  382.          This disables the "xhost +" by commenting out the command.
  383.  
  384.       3) Make sure your /etc/sys_id file has no periods in it.  For
  385.      example, change as root:
  386.  
  387.   hoot.asd.sgi.com
  388.  
  389.          to say
  390.  
  391.   hoot
  392.  
  393.       4) Reboot the machine OR restart a new xdm and X server.  This
  394.      can be done as root with the following command:
  395.  
  396.   (/usr/gfx/stopgfx; killall xdm; /usr/gfx/startgfx) &
  397.  
  398.       5) Log in.  X authorization should be enabled.
  399.  
  400.   If you want to disable X authorization and return to the default
  401.   system state where X clients can connect to the X server from any
  402.   machine, reverse the changes in steps 1 and 2 and repeat step 4.
  403.  
  404.   If you want more information on X authorization, see the manpages for
  405.   xdm(1), Xserver(1), Xsgi(1), Xsecurity(1), xauth(1) and xhost(1).
  406.  
  407.   X AUTHORIZATION AND REMOTE IRIS GL PROGRAMS: One of the major reaons
  408.   for Silicon Graphics shipping its window system so that an X client
  409.   from any machine could connect to the X server was because IRIS GL
  410.   programs running remote using the DGL (distributed GL) protocol didn't
  411.   interoperate with the X authorization mechanism; the dgld daemon that
  412.   would run on the machine with graphics hardware had no way to get the
  413.   correct X authorization information to connect to the X server.
  414.  
  415.   This has been fixed for IRIX 5.2, but the fix only applies to IRIX 5
  416.   binaries running remotely on an IRIX 5.2 system connecting to an IRIX
  417.   5.2 X server.  In particular, remotely run IRIX 4 IRIS GL binaries
  418.   will continue to not interoperate with an IRIX 5.2 X server (or a
  419.   pre-IRIX 5.2 X server).  If you recompile your old IRIS GL binaries
  420.   on IRIX 5.2, they then will work remotely connecting to IRIX 5.2 X
  421.   servers running X authorization.
  422.  
  423.   The bottom line is that if you want an IRIS GL program to run
  424.   remotely on an X server using X authorization, you need to make sure
  425.   the program is an IRIX 5 binary running on an IRIX 5.2 machine and
  426.   the machine with the X server is also an IRIX 5.2 machine.
  427.  
  428.   To avoid a possible misconception: IRIS GL programs RUNNING LOCALLY
  429.   (ie, not using DGL) WILL WORK FINE on an IRIX 5.2 system no matter if
  430.   they are IRIX 4 or IRIX 5 binaries. The problem with X authorization
  431.   is only for REMOTE IRIS GL programs.
  432.  
  433.   Also note that for X authorization to work for remote hosts, the
  434.   remote program must have access to the correct X authorization magic
  435.   cookie (normally read from ~/.Xauthority).  If you don't have a
  436.   shared NFS mounted home directory, you'll probably need to use the
  437.   xauth command to transfer the X authorization magic cookie to the
  438.   remote ~/.Xauthority file.
  439.  
  440.   THE FUTURE:  Hopefully in the next general release of IRIX, a
  441.   mechanism to enable and disable X authorization using a chkconfig
  442.   option will be supported.  The problem with /etc/sys_id not having
  443.   periods will definitely be fixed in the next general release of
  444.   IRIX.  The problem with pre-IRIX 5.2 X servers and binaries not
  445.   interoperating with X authorization will likely not be fixed. Fixing
  446.   the problem required a DGL protocol extension which both the IRIS GL
  447.   program and dgld must know about; this can't be fixed in already
  448.   shipped software.
  449.  
  450.   Under IRIX 5.3, do what you did for IRIX 5.2. There is no chkconfig
  451.   option for X authorization. The problem with periods in hostnames is
  452.   still present in 5.3 as such, but is fixed by patch 518. There is a
  453.   bug in NFS3 which truncates ~/.Xauthority files which is fixed by
  454.   patch 216. See also the descriptions of the shared memory hole and the
  455.   putative X authorization weaknesses below under "security-related
  456.   bugs".
  457.  
  458. ------------------------------
  459.  
  460. Subject:    -7- What security-related bugs does IRIX have?
  461. Date: 4 Jun 1997 00:00:01 EST
  462.  
  463.   (Thanks to Yuri Volobuev <volobuev@t1.chem.umn.edu> for updating 
  464.   several questions in this question.)
  465.  
  466.   Some general comments before we start:
  467.  
  468.   - IRIX is too complex for us to guarantee that this list is complete.
  469.     We only discuss problems we know about. We don't discuss insecurely
  470.     designed systems (like YP) or ways in which you might misconfigure
  471.     your system, only bugs.  We don't discuss third-party software,
  472.     free or not.
  473.  
  474.   - Prudence and space permit us to describe only how to close holes,
  475.     not to exploit them. Try comp.security.unix.
  476.  
  477.   - Some of the fixes involve installing a new version of a setuid
  478.     binary.  Be sure that you 1) make it executable, setuid and owned
  479.     by the correct user and group (or it won't work), and 2) remove the
  480.     old version so bad guys can't use it!
  481.  
  482.   Now for the holes themselves:
  483.  
  484.   - ftp://ftp.cert.org/pub/cert_advisories/CA-92:08.SGI.lp.vulnerability
  485.     describes problems with the permissions of 'lp'-related parts of
  486.     IRIX which allow anyone who can log in as lp to get root access.
  487.     They are fixed in IRIX 4.0.5.  Briefly, the fix is
  488.  
  489.       su root
  490.       cd /usr/lib
  491.       chmod a-s,go-w lpshut lpmove accept reject lpadmin
  492.       chmod go-ws lpsched vadmin/serial_ports vadmin/users vadmin/disks
  493.       cd /usr/bin
  494.       chmod a-s,go-w disable enable
  495.       chmod go-ws cancel lp lpstat
  496.  
  497.   - ftp://ftp.cert.org/pub/cert_advisories/CA-93:17.xterm.logging.vulnerability
  498.     describes a hole in /usr/bin/X11/xterm which allows any user root
  499.     access.  It is fixed in IRIX 5.x.  A fixed version for 4.x is at
  500.     ftp://ftp.sgi.com/sgi/IRIX4.0/xterm/.  The 'fix', incidentally, is
  501.     that logging is completely disabled.
  502.  
  503.   - /usr/bin/under is an unused (!) part of 'rexd'. It is setuid root
  504.     and may allow root access, so 'chmod -s' it just in case. Note that
  505.     SGI ships IRIX with 'rexd' turned off because 'rexd' is itself a
  506.     security problem. It is not shipped in IRIX 5.x.
  507.  
  508.   - ftp://ciac.llnl.gov/pub/ciac/bulletin/f-fy95/f-01.ciac-SGI-IRIX-serial-ports
  509.     describes a race condition in IRIX 4.0.x's
  510.     /usr/lib/vadmin/serial_ports which allows any user to become root
  511.     in IRIX 4.0.x. 'chmod 700' it to close the hole; it will still work
  512.     fine.
  513.  
  514.     /usr/lib/vadmin/serial_ports is part of IRIX 4.0.x and should not
  515.     exist on IRIX 5.x systems, but some users have reported problems
  516.     with upgrading from 4.0.x to 5.x which leave old binaries behind.
  517.     If the file exists on your 5.x system, remove it. (5.x's
  518.     equivalent, /usr/Cadmin/bin/cports, does not have the problem.)
  519.  
  520.   - /usr/bsd/rdist has several holes which allow any user root access in
  521.     all versions of IRIX before 5.3, including the 4.0.5 and 5.x
  522.     binaries on ftp.sgi.com.
  523.  
  524.     Under IRIX 5.2, you can install patch 130 to close all known
  525.     holes.  Under IRIX 4.0.x, you must close the hole with 'chmod -s'.
  526.     rdist will then work only when used by root. If your non-root users
  527.     need 'rdist', there is a free version, which does not need to be
  528.     setuid root and is thus free of all known holes, in
  529.     ftp://usc.edu/pub/rdist/.  Make sure you get version 6.1 beta 3 or
  530.     later. IRIX 5.3's rdist is derived from this version and is thus
  531.     equally safe; presumably ordist is the IRIX 5.2-patch 130 rdist and
  532.     is also safe.
  533.  
  534.     As for advisories, CERT advisory CA-91:20, at
  535.     ftp://ftp.cert.org/pub/cert_advisories/CA-91:20.rdist.vulnerability
  536.     is badly out of date, and
  537.     http://www.8lgm.org/advisories/[8lgm]-Advisory-1.UNIX.rdist.23-Apr-1991
  538.     and
  539.     http://www.8lgm.org/advisories/[8lgm]-Advisory-26.UNIX.rdist.20-3-1996.html
  540.     may not describe all of the known holes.
  541.  
  542.   - The 'lpr' subsystem in every version of IRIX before 5.3 has several
  543.     holes which allow a non-root user to become root. Note that 'lp' is
  544.     SGI's usual printing system; you only need 'lpr' if you need to deal
  545.     with remote printers. If you don't need 'lpr', make sure it isn't
  546.     installed. (It lives in the eoe2.sw.lpr subsystem.) If you do need
  547.     'lpr', there are fixed versions at
  548.  
  549.       ftp://ftp.sgi.com/sgi/IRIX4.0/lpr/lpr.latest.Z
  550.       ftp://ftp.sgi.com/sgi/IRIX5.0/lpr/lpr.latest.Z
  551.  
  552.     The versions dated 29 and 26 April, respectively, work with NIS
  553.     (YP).  The IRIX 5.x version is also available as patch 131.
  554.  
  555.   - /usr/sbin/cdinstmgr is setuid root in IRIX 4.0.5[A-F] and
  556.     /etc/init.d/audio is setuid root in IRIX 5.2. They are scripts;
  557.     setuid scripts are a well-known Unix security problem. IRIX ignores
  558.     the setuid bit by default, but 'chmod -s' the scripts just in case.
  559.  
  560.   - ftp://sgigate.sgi.com/Security/19950209-01-P describes a bug in
  561.     colorview in IRIX 5.x before 5.3, which allows anyone to use it to
  562.     read any file regardless of permissions, and gives a fix.
  563.  
  564.   - /usr/bin/newgrp is group-writable in IRIX 5.2. It doesn't need to
  565.     be, and it might be a problem depending on your use of group sys
  566.     and/or the presence of the 'sadc' bug (described elsewhere in this
  567.     list) on your system. 'chmod g-w' it.
  568.  
  569.   - /usr/sbin/printers has a bug in IRIX 5.2 (and possibly earlier 5.x
  570.     versions) which allows any user to become root. Apply patch 5. You
  571.     might want to 'chmod -s' it while you're waiting.
  572.  
  573.   - /usr/sbin/sgihelp has a bug in IRIX 5.2 (and possibly earlier 5.x
  574.     versions) which allows any user to become root. This is so bad that
  575.     the patch (#65, along with the prerequisite patch 34) is FTPable
  576.     from ftp://ftp.sgi.com/security/, and SGI is preparing a CD
  577.     containing only that patch. Call the TAC if you can't FTP. You
  578.     should 'chmod -x /usr/sbin/sgihelp' while you're waiting.
  579.  
  580.   - The inst which comes with patch 34 (for IRIX 5.2), which is required
  581.     for installation of all other patches (even those with lower
  582.     numbers) saves old versions of binaries in /var/inst/patchbase. It
  583.     does not remove execution or setuid permissions! 'chmod 700' that
  584.     directory so evil users can't get to the old binaries. The bug is
  585.     fixed in patch 82 for IRIX 5.2 and in IRIX 5.3.
  586.  
  587.   - http://www.8lgm.org/advisories/[8lgm]-Advisory-11.UNIX.sadc.07-Jan-1992
  588.     describes a hole in the System V system activity reporting program
  589.     /usr/lib/sa/sadc which allows any user to write files with the
  590.     permissions of that program. This bug is present in all versions of
  591.     IRIX through 5.3, but since /usr/lib/sa/sadc is only setgid sys it
  592.     can only be used to change groups sys-writable files or write files
  593.     in group sys-writable directories.  If you don't use the system
  594.     activity reporter you might want to 'chmod -s /usr/lib/sa/sadc' just
  595.     to be safe. Because this hole isn't serious it isn't scheduled to be
  596.     closed, but write permission for group sys has been removed from
  597.     most directories where it wasn't necessary in IRIX 5.3, and a few
  598.     more (/dev/*dsk) will be fixed in a later release.
  599.  
  600.   - /usr/etc/mount_dos, IRIX's DOS-filesystem floppy mounter, has a
  601.     serious bug in IRIX 5.2 (and probably earlier releases of 5.x as
  602.     well) which allows anyone with an account on and physical access to
  603.     a machine with a floppy drive root access.  This bug can be fixed
  604.     with patch 167 and is reportedly fixed in IRIX 5.3.  Perhaps the
  605.     easiest interim "fix" (which essentially disables all removable
  606.     media drives) is to disable mediad: "mediad -k" kills the current
  607.     instance of mediad, and "chkconfig mediad off" prevents mediad from
  608.     starting during the next reboot.
  609.  
  610.   - ftp://ftp.cert.org/pub/cert_advisories/CA-95%3A17.rpc.ypupdated.vul
  611.     describes a security hole which is present in /usr/etc/rpc.ypupdated
  612.     in all versions of IRIX. It is completely unnecessary in most
  613.     networks; the only instance that we could think of that might
  614.     require this daemon would be NIS networks that include Sun diskless
  615.     clients. You should probably comment it out of /etc/inetd.conf, or
  616.     just not install the nfs.sw.nis subsystem, of which it is a part. It
  617.     is commented out by default in IRIX 5.3.
  618.  
  619.   - ftp://sgigate.sgi.com/Security/19950301-01-P373
  620.     describes a bug in /usr/lib/desktop/permissions in IRIX 5.2, 6.0 and
  621.     6.0.1 which allows any user to change the permissions of any file to
  622.     anything. (Click on "Apply" twice fast, then click "Cancel" to
  623.     dismiss the root password window.) It is fixed in patch 373 for IRIX
  624.     5.2, 6.0 and 6.0.1 and in IRIX 5.3. Until you patch or upgrade,
  625.     'chmod -s' it to close the hole.
  626.  
  627.   - sendmail is a complex program in which new security holes are
  628.     discovered almost daily. Some of these holes enable unprivileged
  629.     users (and in one case even *remote* users!) to gain root access.
  630.     The safest course of action seems to be to use the most recent
  631.     sendmail possible.
  632.  
  633.     Recent sendmail patches also fix a bug present in every IRIX
  634.     sendmail before 5.3: /usr/bsd/newaliases (which is just a symlink to
  635.     /usr/lib/sendmail) creates /etc/aliases.{dir,pag} with mode 666. Any
  636.     user can thus add aliases which can run programs or steal mail.
  637.     Close the hole with 'chmod go-w /etc/aliases.dir /etc/aliases.pag'.
  638.     sendmail doesn't change those files' permissions once they exist, so
  639.     a) you should check them even if you've installed a sendmail in
  640.     which the problem is fixed and b) once they exist and have proper
  641.     permissions, you're OK.
  642.  
  643.   - /usr/etc/arp has a hole in IRIX 5.2 and earlier which allows any
  644.     user to read files with 'arp's permissions, i.e. group sys.  Close
  645.     the hole with 'chmod -s'. This prevents non-root users from using
  646.     'arp' at all, but they don't generally need it. The hole is closed
  647.     in IRIX 5.3.
  648.  
  649.   - SoftWindows 1.25 (which is distributed by SGI in Desktop Support
  650.     Environment 1.0 and HotMix 11) includes an installation script which
  651.     executes Netscape as root. This can be used to gain root access,
  652.     etc.  Patch 905 (if your Softwindows is installed as the
  653.     "SoftWindows" subsystem) or 908 (if it's in the "swin" subsystem)
  654.     fixes the script.
  655.  
  656.   - ftp://ftp.cert.org/pub/cert_advisories/CA-95:14.Telnetd_Environment_Vulnerability
  657.     describes a vulnerability in telnetd which is present in IRIX before
  658.     6.2. A remote user can use telnet/telnetd to pass environment
  659.     variables to login which cause login to use an arbitrary shared
  660.     library. If the same user can place a shared library on the system
  661.     running telnetd (e.g. by depositing it in an incoming FTP
  662.     directory), that user can gain root permissions. There is a related
  663.     hole in login(1): it allows one to set LD_ envariables from the
  664.     command line, and, if they are already present in its environment,
  665.     passes them to programs which it invokes. Patches 1010, 1020 and
  666.     1143 for various versions of IRIX close the holes, as does IRIX 6.2.
  667.  
  668.   - ftp://sgigate.sgi.com/Security/19960101-01-PX describes a hole in
  669.     the objectserver which allows a local or remote user to become
  670.     root. Patch 1052 to IRIX 5.2, 6.0 and 6.0.1, patch 1048 to IRIX 5.3
  671.     and patch 1090 to IRIX 6.1 close the hole. Note that patch 1048
  672.     (and perhaps its cousins) comes with a mediad which doesn't
  673.     properly handle audio CDs, and that its successor, patch 1096
  674.     (successors to 1052 and 1090 are not yet available) breaks
  675.     cformat(1M); see the admin FAQ.
  676.  
  677.   - ftp://sgigate.sgi.com/Security/19960102-01-P
  678.     describes a hole in /usr/pkg/bin/pkgadjust (part of the SVR4 pkg
  679.     system, in eoe2.sw.oampkg, not installed by default) which allows
  680.     local users to overwrite files and execute arbitrary programs as
  681.     root. To close the hole, either remove eoe2.sw.oampkg or 'chmod -s
  682.     /usr/pkg/bin/pkgadjust'. If you do leave eoe2.sw.oampkg installed,
  683.     note that /usr/pkg/bin/abspath is setuid root as well. This is not
  684.     yet known to be a security problem, but is certainly not necessary,
  685.     and the careful admin will want to 'chmod -s' it as well. Since
  686.     neither program needs to be setuid, no patch is necessary. Future
  687.     releases of IRIX will not install them setuid.
  688.  
  689.   - ftp://sgigate.sgi.com/Security/19960301-01-P and
  690.     ftp://ftp.cert.org/pub/cert_advisories/CA-96.09.rpc.statd describe a
  691.     hole in rpc.statd (see statd(1M)), present in all IRIXes before 6.2,
  692.     which allows a remote user to mount denial-of-service attacks or
  693.     create or remove files as root. Patch 1226 (IRIX 5.2), 1128 (6.0 and
  694.     6.0.1) and 1391 (5.3) close the hole. There is no patch for IRIX
  695.     6.1. The hole is fixed in IRIX 6.2.
  696.  
  697.   - The xdm(1) manpage(!) describes a bug in IRIX 5.x (at least) which
  698.     allows a user to connect to a local display even when X
  699.     authorization should prevent one from doing so. (Fortunately, this
  700.     doesn't work for remote displays.) Close the hole with patch 1075,
  701.     or just turn off shared memory transport by adding the option
  702.     '-shmnumclients 0' to the X command in /usr/lib/X11/xdm/Xservers.
  703.     See also the lengthy discussion of X authorization above and the
  704.     description of the putative X authorization weaknesses below.
  705.  
  706.   - LicenseManager 2.0 (a prerequisite for some of the free software
  707.     on Silicon Surf) a) allows any user to manipulate licenses and, b)
  708.     when one adds a new license, may delete old, unrelated licenses. The
  709.     problem is fixed in LM 2.0.1.  Also, LicenseManager 1.x through 3.0 
  710.     have bugs in them which can allow any user to become root.  'chmod 
  711.     -s /usr/etc/LicenseManager' will close them; however, this will 
  712.     preclude any user other than root from using LicenseManager to 
  713.     manipulate licenses.
  714.  
  715.   - ftp://info.cert.org/pub/cert_advisories/CA-96.08.pcnfsd describes a
  716.     bug which allows remote users to run commands as root on a pcnfsd
  717.     server. The bug is present in the version of pcnfsd which SGI
  718.     provides for IRIX 5.3, but not in that for IRIX 6.2 (or other IRIX
  719.     6.x?). It is fixed by patch 1179 for IRIX 5.3.
  720.  
  721.   - /usr/bin/rmail has a bug which allows a local user to assume the
  722.     permissions of group mail, and thus (most importantly) read anyone's
  723.     mail. It is fixed in patch 1273 for IRIX 5.2-6.1 and 1281 for 6.2.
  724.  
  725.   - ftp://sgigate.sgi.com/Security/19960501-01-PX and
  726.     ftp://sgigate.sgi.com/Security/19960801-01-PX describe holes in the
  727.     desktop administration tools which allow users to change permissions
  728.     on and edit files which they do not own. They are closed by patches
  729.     1519, 1518, 1517 and 1516 for IRIX 5.2, 5.3, 6.1 and 6.2
  730.     respectively.
  731.  
  732.   - /usr/bin/X11/cdplayer and /usr/sbin/datman (also known as 'cdman')
  733.     have security holes in them that can allow users to execute 
  734.     arbitrary programs as root.  At this time, SGI has not released 
  735.     patches for these programs yet, so the way to close the hole is via
  736.     'chmod -s /usr/bin/X11/cdplayer /usr/sbin/datman'.  This will
  737.     unfortunately prevent non-root users from using cdman, datman, and 
  738.     cdplayer; other Motif-based CD players are available on the 
  739.     Internet which may not share cdplayer's vulnerabilities.  
  740.     These problems are described in more detail in AUSCERT advisories
  741.     ftp://ftp.auscert.org.au/pub/auscert/advisory/AA-96.11.SGI.cdplayer.vul
  742.     and
  743.     ftp://ftp.auscert.org.au/pub/auscert/advisory/AA-96.20.SGI.datman.cdman.vul
  744.    
  745.   - /var/rfindd/fsdump has a security hole in it which allows users to
  746.     overwrite arbitrary files and (in so doing) gain root access. 
  747.     'chmod -s /var/rfindd/fsdump' will close the hole and also disable
  748.     rfindd.
  749.  
  750.   - /sbin/suid_exec, a component of ksh that assists ksh in running 
  751.     setuid shell scripts, has a security hole in it that allows users
  752.     to execute arbitrary programs as root.  'chmod -s /sbin/suid_exec'
  753.     will close the hole and also prevent ksh from executing setuid 
  754.     shell scripts.  (Execution of setuid shell scripts is off by default
  755.     on most releases of IRIX anyway.)
  756.  
  757.   - /usr/Cadmin/bin/csetup, the "EZsetup" system setup manager, has a 
  758.     security hole in it that allows users to execute arbitrary programs 
  759.     as root.  
  760.  
  761.   - ftp://sgigate.sgi.com/security/19961203-01-PX describes a vulnerability
  762.     in /usr/lib/print/netprint, which allows any local user to become root.
  763.     Apply following patch 1685 (for 5.3/6.1) or 2022 (for 6.2).  5.2 doesn't
  764.     have netprint.  Note, that this patch may break printing.  To fix it,
  765.     add this to the top of /etc/init.d/lp
  766.  
  767.     TMPDIR=/var/tmp
  768.     export TMPDIR
  769.     HOME=/var/spool/lp
  770.     export HOME
  771.     LOGNAME=lp
  772.     export LOGNAME
  773.  
  774.     then run "/etc/init.d/lp stop ; /etc/init.d/lp start"
  775.  
  776.  
  777.   These bugs have not yet been fixed:
  778.  
  779.   - /usr/bin/lp has several bugs that allow any local user to gain lp 
  780.     privileges.  If you don't need its functionality, consider removing the
  781.     suid bit from lp.  If you do need it, you can "wrap" the lp binary
  782.     with a wrapper that cleans up critical environment variables 
  783.     (e.g. PATH), checks the command line for shell metacharacters and
  784.     length limits.
  785.  
  786.   - The default root crontab contains a call to /usr/etc/fsr.  By default, 
  787.     under certain conditions it can be used to obtain root privileges.
  788.     Edit root's crontab and add "-f /var/adm/.fsrlast" option to the
  789.     fsr command line.
  790.  
  791.   - /usr/etc/cvpcsd is part of the CaseVision WorkShop package.  It's 
  792.     invoked by inetd with root priviledges.  It has a vulnerability that 
  793.     allows any root priviledges.  It has a vulnerability that allows any
  794.     local user to overwrite any file on the system, and, under certain 
  795.     conditions, become root.
  796.     Check your /etc/inetd.conf for this or a similar line:
  797.  
  798.     sgi_pcsd/1  dgram   rpc/udp wait    root    ?/usr/etc/cvpcsd        pcsd 
  799. -L
  800.  
  801.     if it's there, consider commenting it out.  (Don't forget to 
  802.     'killall -HUP inetd' after you've commented it out.)
  803.  
  804.   - /usr/lib/InPerson/inpview, part of the InPerson desktop conferencing 
  805.     tool, has a vulnerability that allows any local user to become root.  
  806.     If you don't need InPerson functionality, remove the suid bit from
  807.     inpview (with 'chmod u-s /usr/lib/InPerson/inpview').  If you do
  808.     need it, restrict execution privileges to the trusted group of 
  809.     individuals that have access to the console.
  810.  
  811.   - /usr/bin/startmidi that comes with the standard IRIX 5.3 distribution 
  812.     has a vulnerability that allows any local user to become root.  
  813.     However, startmidi that comes with Desktop Special Edition 1.1 is not
  814.     vulnerable to this problem.  IRIX 6.2 doesn't seem to be vulnerable
  815.     either.  Check your machine by running "showfiles | grep startmidi".  
  816.     If your output is:
  817.  
  818.     f 64563 18688 dmedia_eoe.sw.midi      usr/sbin/startmidi
  819.  
  820.     your machine is most likely not vulnerable to this problem.  If you see
  821.  
  822.     f 46022 18608 dmedia_eoe.sw.midi      usr/sbin/startmidi
  823.  
  824.     your system is probably vulnerable, so remove the suid bit from 
  825.     startmidi (with 'chmod u-s /usr/sbin/startmidi').  If it's
  826.     neither of the above, remove the suid bit just to be safe. There's no
  827.     official advisory or workaround for this problem.
  828.  
  829.   - /usr/lib/so_locations.old can acquire random permissions after an
  830.     'inst' session in IRIX 5.3, due to a linker bug. It may become both
  831.     executable and setuid and/or setgid. It is not a script but could be
  832.     used as one; setuid scripts are a well-known Unix security problem.
  833.     IRIX ignores the setuid bit by default, but 'chmod -xs' it just in
  834.     case. The linker bug should be fixed in IRIX 6.2.
  835.  
  836.   - /usr/Cadmin/bin/csetup, the "EZsetup" system setup manager, has a 
  837.     security hole in it that allows users to execute arbitrary programs 
  838.     as root.  'chmod -s /usr/Cadmin/bin/csetup' will close the hole
  839.     but prevent non-root users from running csetup.  This bug is present
  840.     in IRIX 5.3 and probably in later versions as well.
  841.  
  842.   - xwsh recognizes escape sequences which remap keys. An evildoer
  843.     can place escape sequences in a file or filename which, when passed
  844.     to xwsh to be displayed, remap keys to unexpected strings or to
  845.     xwsh internal functions. The escape sequences are not displayed and
  846.     may not be detected by the victim.
  847.  
  848.     Programs which can pass these escape sequences to xwsh include
  849.     'cat', 'more', /bin/mail and /usr/bsd/Mail, and other programs such
  850.     as mail and news agents which call these programs to display text.
  851.     Programs which display filenames, such as 'ls' and 'find', can pass
  852.     escape sequences in filenames to xwsh.
  853.  
  854.     Programs which do not recognize the remapping sequences, such as
  855.     xterm and MediaMail, and programs which remove escape sequences
  856.     from displayed text or replace them with safe characters, such as
  857.     'ls' with the '-b' or '-q' option, 'more' with the '-r' option, the
  858.     'less' pager and the Elm mailer's built-in pager, are safe.
  859.  
  860.     This vulnerability is inherent in the ANSI standard escape codes
  861.     which xwsh respects; any terminal or terminal emulator which
  862.     recognizes these sequences has this problem. Recognition of these
  863.     escape codes ought to be optional, e.g. controlled by an X
  864.     resource. It will be in IRIX 6.2 (although a cursory search of the
  865.     man page xwsh(1) does not reveal how to do so).  No patch is planned
  866.     for earlier versions of IRIX.
  867.  
  868.     The safest workaround is to use xterm instead of xwsh. The next best
  869.     is to run only safe programs and/or display only safe text in xwsh
  870.     windows. If you use xwsh, alias 'ls' to 'ls -b' and 'more' to 'more
  871.     -r'. You could alias 'cat' to 'cat -v', or (to avoid corrupting
  872.     files when using 'cat' in pipelines) train yourself not use 'cat' to
  873.     display files.
  874.  
  875.   - ftp://ftp.cert.org/pub/cert_advisories/CA-95:13.syslog.vul
  876.     describes a problem with the syslog(3) system call in which data
  877.     passed to syslog(3) can corrupt the stack and cause execution of
  878.     arbitrary code. If a program will accept data from an untrusted
  879.     (even remote) user and pass it to syslog(3) without bounds checking,
  880.     a *very* clever user can usurp the permissions of that program.
  881.  
  882.     The hole will be closed in IRIX 6.2. There are no patches for
  883.     current versions of IRIX, and none are planned, because SGI finds it
  884.     difficult to distribute an installable patch to libc.so (where
  885.     syslog(3) lives). However, patch 1146 prevents sendmail from passing
  886.     dangerous data to syslog(3) in the first place, which prevents
  887.     exploitation of the hole via sendmail only.
  888.  
  889.   - /usr/lib/X11/app-defaults/ISDN, the X resources file for the ISDN
  890.     confidence test module which is part of at least some versions of
  891.     SGI's ISDN software (details welcome), is both executable and setuid
  892.     root.  It is not a script but could be used as one; setuid scripts
  893.     are a well-known Unix security problem.  IRIX ignores the setuid bit
  894.     by default, but 'chmod -xs' it just in case. This will be fixed in
  895.     IRIX 6.2.
  896.  
  897.   - http://www.stardot.net/~hhui/SDN-advisories/SDN-2-sgi-videoframer a)
  898.     describes a hole in the VideoFramer development software which
  899.     allows a local user to overwrite files, and b) points out that VF
  900.     includes many setuid scripts, which are a well-known Unix security
  901.     problem (although not in the default IRIX configuration). Fix both
  902.     problems with 'chmod -s /usr/video/vfr/*'.
  903.  
  904.   - /usr/gfx/setmon has holes (present at least in IRIX 5.3) which allow
  905.     a local user to read files which should be readable only by root and
  906.     to crash the machine. 'chmod -s' it. (Thanks to Hui-Hui Hu
  907.     <hhui@stardot.net>.)
  908.  
  909.   - /usr/etc/uncompvm in IRIXes up to 5.3 and 6.1 is setgid sys. It
  910.     doesn't need to be (crash dumps are readable only by root, not by
  911.     group sys) so 'chmod -s' it. It will not be setgid sys in IRIX 6.2.
  912.     (Thanks to Hui-Hui Hu <hhui@stardot.net>.)
  913.  
  914.   - par(1) will display data read by a setuid program, even if the
  915.     program would not itself have printed that data. One can thus use
  916.     par and a suitably leaky setuid program (known examples include
  917.     arp(1M), setmon(1G) and uncompvm(1M)) to read files for which one
  918.     would otherwise not have permission. This will be fixed by a
  919.     patch to IRIX 5.3 and in IRIX 6.2.
  920.  
  921.   - ftp://ftp.cert.org/pub/cert_advisories/CA-96.19.expreserve describes
  922.     a bug in expreserve which allows any user to overwrite any file on
  923.     the system. ftp://sgigate.sgi.com/Security/19960802-01-I explains
  924.     that since SGI's expreserve is setgid sys rather than setuid root as
  925.     on some othere systems (yay SGI!), it can only overwrite files which
  926.     can be written by group sys. Since there are no important files
  927.     which can be written by group sys, no patch is planned. The bug will
  928.     be fixed in a future release. Make sure that there are, indeed, no
  929.     important files on your system which are writable by group sys. If
  930.     you don't need expreserve, 'chmod -s' it.
  931.  
  932.   The following advisories describe holes whose presence in IRIX we
  933.   can't confirm or deny at present:
  934.  
  935.   http://www.8lgm.org/advisories/[8lgm]-Advisory-12.UNIX.suid_exec.27-Jul-1991
  936.   ftp://ftp.cert.org/pub/cert_advisories/CA-94%3A15.NFS.Vulnerabilities
  937.   ftp://ftp.cert.org/pub/cert_bulletins/VB-95%3A08.X_Authentication_Vul
  938.   ftp://ftp.cert.org/pub/cert_advisories/CA-96.02.bind
  939.  
  940. ------------------------------
  941.  
  942. Subject:    -8- I think I've found a security hole in IRIX; whom should
  943.                 I notify?
  944. Date: 31 May 1995 00:00:01 EST
  945.  
  946.   First, call the TAC as for any bug.  Next, send email to
  947.   security-alert@sgi.com.  You can also notify CERT <cert@cert.org>, who
  948.   will contact the appropriate people from their contact list. They may
  949.   take some time.
  950.  
  951. ------------------------------
  952.  
  953. Subject:    -9- How can I get around the root and/or PROM passwords?
  954. Date: 20 Apr 1996 00:00:01 EST
  955.  
  956.   To get around the root password, start 'inst' from an IRIX CD or tape
  957.   as you would if you wanted to install software. (See chapter 3 of the
  958.   Software Installation Administrator's Guide.) If you've set a PROM
  959.   password, you'll need to provide it or circumvent it first; see below.
  960.   Say 'admin shroot' to get a root shell. You can then do any of the
  961.   following:
  962.  
  963.   - use 'passwd' to change root's password
  964.   - 'setenv TERM iris-tp' and 'vi/etc/passwd'
  965.   - if /etc/passwd is really hosed, 'mv' the remains out of the way and
  966.     'echo root::0:0:root:/:/bin/sh > /etc/passwd'.
  967.  
  968.   Alternatively, if your machine is an NIS client you can change the uid
  969.   of an NIS account to 0 from the server and do a 'ypmake'.
  970.  
  971.   If you've lost your PROM password but can still log in as root, you
  972.   can zero the PROM password with 'nvram passwd_key ""'. If not, you'll
  973.   have to disable the PROM password via the hardware. On a 4D/35 or
  974.   Crimson, find the battery which maintains the nvram ("non-volatile
  975.   RAM") and remove it. On an Indigo or Indy, find the nvram chip itself
  976.   and remove it. On an Indigo^2, remove the jumper described in the
  977.   owner's manual. This may be a good time to call SGI.
  978.  
  979. ------------------------------
  980.  
  981. Subject:   -10- What firewalls are available on SGI/IRIX platforms?
  982. Date: 16 Mar 1996 00:00:01 EST
  983.  
  984.   Ping Huang <pshuang@sgi.com> writes:
  985.  
  986.   SGI is an OEM for Gauntlet (from Trusted Information Systems), meaning
  987.   that SGI sells and supports Gauntlet directly. See
  988.   http://www.tis.com/docs/Products/gauntlet.html for general Gauntlet
  989.   product information. See your SGI sales person for specific
  990.   information about Gauntlet for IRIX.
  991.  
  992.   I believe that is the only commercial firewall product currently
  993.   available, although there are freely distributable (but unsupported
  994.   and possibly dated) alternatives like the TIS Firewall Toolkit. If you
  995.   want more choices, please make your desires for availability on the
  996.   SGI/IRIX platform known to your favorite firewall vendor(s).
  997.  
  998. ------------------------------
  999.  
  1000. End of sgi/faq/security Digest
  1001. ******************************
  1002. -- 
  1003. The SGI FAQ group <sgi-faq@viz.tamu.edu>   http://www-viz.tamu.edu/~sgi-faq/
  1004. Finger us for info on the SGI FAQs, or look in ftp://viz.tamu.edu/pub/sgi/.
  1005.