Subject: SGI security Frequently Asked Questions (FAQ)
Supersedes: <security_827305498@viz.tamu.edu>
Date: 6 Apr 1996 07:04:25 GMT

Posting-Frequency: Twice monthly
URL: http://www-viz.tamu.edu/~sgi-faq/

    SGI security Frequently Asked Questions (FAQ)

This is one of the Silicon Graphics FAQ series, which consists of:

    SGI admin FAQ - IRIX system administration
    SGI apps FAQ - Applications and miscellaneous programming
    SGI audio FAQ - Audio applications and programming
    SGI diffs FAQ - Changes to the other FAQs since the last posting
    SGI graphics FAQ - Graphics and user environment customization
    SGI hardware FAQ - Hardware
    SGI impressario FAQ - IRIS Impressario
    SGI inventor FAQ - IRIS Inventor
    SGI misc FAQ - Introduction & miscellaneous information
    SGI movie FAQ - Movies
    SGI performer FAQ - IRIS Performer
    SGI pointer FAQ - Pointer to the other FAQs
    SGI security FAQ - IRIX security

Read the misc FAQ for information about the FAQs themselves. Each FAQ is
posted to comp.sys.sgi.misc and to the news.answers and comp.answers
newsgroups (whose purpose is to store FAQs) twice per month. If you
can't find one of the FAQs with your news program, you can get it from

    ftp://viz.tamu.edu/pub/sgi/faq/
    ftp://rtfm.mit.edu/pub/usenet/news.answers/sgi/faq/

(rtfm.mit.edu is home to many other FAQs and informational documents,
and is a good place to look if you can't find an answer here.) The FAQs
are on the World Wide Web at

    http://www-viz.tamu.edu/~sgi-faq/

If you can't use FTP or WWW, send mail to mail-server@rtfm.mit.edu with
the word 'help' on a line by itself in the text, and it will send you a
document describing how to get files from rtfm.mit.edu by mail. Send the
command 'send usenet/news.answers/sgi/faq/misc' to get the SGI misc FAQ,
and similarly for the other FAQs. Send the command 'send
usenet/news.answers/internet-services/access-via-email' to get the
"Accessing the Internet by E-Mail FAQ".

You may distribute the SGI FAQs freely and we encourage you to do so.
However, you must keep them intact, including headers and this notice,
and you must not charge for or profit from them. Contact us for other
arrangements. We can't be responsible for copies of the SGI FAQs at
sites which we do not control, and copies published on paper or CD-ROM
are certain to be out of date. The contents are accurate as far as we
know, but the usual disclaimers apply. Send additions and changes to
sgi-faq@viz.tamu.edu.

Topics covered in this FAQ:
---------------------------
   -1- Where can I learn about IRIX and Unix security?
   -2- How can I check my system for security problems?
!  -3- How can I configure IRIX to be more secure?
   -4- How can I log more information about logins?
   -5- How can I make an anonymous or restricted FTP account?
   -6- How can I get X authorization to work?
!  -7- What security-related bugs does IRIX have?
   -8- I think I've found a security hole in IRIX; whom should I notify?
   -9- How can I get around the root and/or PROM passwords?
  -10- What firewalls are available on SGI/IRIX platforms?

----------------------------------------------------------------------

Subject:    -1- Where can I learn about IRIX and Unix security?
Date: 30 Nov 1995 00:00:01 EST

  IRIX: Look in ftp://sgigate.sgi.com/Security/ for SGI security
  advisories and patches.
  http://www.sgi.com/Products/WebFORCE/Security.html lists that and
  some other security resources. An article in the Jul/Aug 1994
  Pipeline discusses general Unix security with some IRIX-specific
  aspects.

  Unix in general: Read
  ftp://rtfm.mit.edu/pub/usenet/news.answers/security-faq and the books
  and papers listed therein for general discussions of Unix security.
  Look in ftp://ftp.cert.org/, ftp://ciac.llnl.gov/pub/ciac/ and
  http://www.8lgm.org/ for CERT, CIAC and 8lgm material (respectively)
  and general security information and tools.  8lgm advisories may also
  be obtained by mail by saying 'echo help | mail
  8lgm-fileserver@bagpuss.demon.co.uk'.  If you have a lot of spare
  time, consider the comp.security.unix newsgroup and/or the bugtraq
  mailing list (bugtraq-request@fc.net, archived at
  http://www.eecs.nwu.edu/~jmyers/bugtraq/).

------------------------------

Subject:    -2- How can I check my system for security problems?
Date: 09 Apr 1995 00:00:01 EST

  Get Nate Sammons' <nate@vis.colostate.edu> 'rscan' (formerly
  'securscan') from ftp://ftp.vis.colostate.edu/pub/rscan/ (and see its
  documentation, etc. at http://www.vis.colostate.edu/rscan/).  It
  checks for many bugs and problems, both specific to IRIX and generic
  to Unix.  You might also want to try a generic Unix security-checking
  tool such as COPS, tiger or SATAN and/or a password checker such as
  Crack. The security FAQ referenced above gives their locations.

------------------------------

Subject: !  -3- How can I configure IRIX to be more secure?
Date: 30 Mar 1996 00:00:01 EST

  Several aspects of SGI's default IRIX configuration were chosen for
  convenience, not security. Unless your machine is not networked, you
  may be more concerned about security than SGI assumed.  Note that
  these items have been discussed on Usenet many times, and Usenet
  chatter is not a good way to change SGI policy. If they bother you,
  complain to your sales rep and then fix them yourself as follows.

  Under any version of IRIX,

  - Several accounts come without passwords, including (but not limited
    to) guest, 4Dgifts, demos, tutor, tour and particularly lp. Examine
    /etc/passwd and lock all unnecessarily open accounts.  Note that 1)
    parts of IRIX (e.g. 'inst') use the open guest account by default,
    and 2) remote 'lp' clients need access to the lp account to print,
    so you'll need to make other arrangements. Completists may wish to
    read CERT advisory CA-95:15, at
    ftp://info.cert.org/pub/cert_advisories/CA-95%3A15.SGI.lp.vul, and
    SGI advisory 19951002-01-I, at
    ftp://sgigate.sgi.com/Security/19951002-01-I.

  - 'xdm' does 'xhost +' by default when you log in. This allows anyone
    to open windows on your display and even to record what you type at
    your keyboard. Close this hole by removing the 'xhost +' from
    /usr/lib/X11/xdm/Xsession, /usr/lib/X11/xdm/Xsession-remote and (in
    IRIX 5.x) /usr/lib/X11/xdm/Xsession.dt. In IRIX 5.2 and later you
!   can use X authorization to control access to remote displays; see
!   below. In IRIX 5.1.x and earlier X authorization doesn't work, so
    you'll need to use 'xhost' judiciously to get to remote displays:
!   say 'xhost +localhost' to run DGL programs and 'xhost +otherhost' to
!   display remote X programs.

  - At least some of the possible default values of the PATH
    environment variable begin with the current directory. (The system
    interprets either a period or the empty string in any component of
    PATH as the current directory. PATH is colon-separated, so if it
    begins with a colon the first component is the empty string.) This
    exposes you to Trojan horse programs. Set PATH to a safe value
    (remove the current directory, or at least move it to the end) in
    /etc/cshrc and/or /etc/profile for regular users and /.login for
    root.

  - By default, /etc/config/ypbind.options contains the -ypsetme
    option. This allows someone who can fake your IP address to change
    your YP binding. Remove the -ypsetme option to close the hole and
    add the -s option for a little extra protection. Comment out the
    invocations of 'ypset' in /var/yp/make.script and /var/yp/ypmake to
    avoid error messages.  If your site runs ypbind with the -v
    (verbose) option, you may also want to add 'YPSET=true' to
    /etc/config/ypmaster.options and comment out the 'ypset' line in
    /var/yp/ypmake. See the ypbind(1) and ypset(1) manpages for more.

  - If you use SLIP (see slip(1M)), be sure that SLIP accounts' home
    directories are not world-writable. SLIP accounts are uid 0, so
    it's bad if just anyone can mess with their .forward files and the
    like.  /tmp, which is recommended in the "IRIX Advanced Site and
    Server Administration Guide", is necessarily world-writable and a
    bad choice.  You may want to make an empty, root-owned, mode 755
    directory to the effect of /usr/slip and use that. Any number of
    SLIP accounts can use a single home directory without conflict.

  - Add '-a' to the rlogind and rshd lines in /etc/inetd.conf to require
    remote hostnames and addresses to match.  You *might* want to
    disallow .rhosts files by adding the '-l' flag as well, but this
    removes real functionality and should not be done without reason.
    See the rlogind(1M) and rshd(1M) manpages.  Note that rlogind's '-l'
    flag does not work in IRIX 5.2. It does work in IRIX 5.3.

  - The default root crontab in current IRIXes
    (/var/spool/cron/crontabs/root) creates the SYSLOG and cron log with
    group and world read permission. Change the '033' on lines 25 and 27
    to '077' to prevent non-superusers from reading these files.

  - By default, xdm looks for X terminal login requests on port
    177. This is no different (for security purposes) than allowing
    rlogin or telnet connections, but it might be undesirable in some
    environments. Edit /var/X11/xdm/Xaccess to restrict this access,
    e.g. by placing a `!' in front of each of the two lines which begin
    with an asterisk to prevent all XDMCP requests.

  - /etc/init.d/rmtmpfiles resets the permissions on /tmp and /var/tmp
    at every bootup. By default, permissions are set to 1777; the '1'
    means sticky, so one user can't remove another's temporary files. If
    one does 'chkconfig nostickytmp on', permissions are set to 777 and
    any user can remove another's temporary files. Don't do this: it
    allows a variety of attacks involving race conditions in setuid
    programs. A related class of attacks is described in
    ftp://ciac.llnl.gov/pub/ciac/bulletin/f-27.permissions-on-tmp.asc,
    but note that Sun's tmpfs is not an essential component of the hole.

  - Non-root users can give away files. This can be used to defeat
    accounting and quotas. Set the 'restricted_chown' kernel variable to
    1 to allow only root to give away files. This may break some
    programs which depend on unrestricted chown, e.g. /bin/mail (when
    delivering to an NFS volume without root access) as discussed in the
    admin FAQ. (Thanks to Jonathan Rozes <jrozes@tufts.edu> for this and
    the next item.)

  - NFS connections to unprivileged ports are accepted by default. Set
    the 'nfs_portmon' kernel variable to 1 to reject NFS connections
    to unprivileged ports.

  - /etc/inetd.conf enables some unnecessary services. The 'echo'
    and 'chargen' services can allow a denial-of-service attack, as
    described, for example, in CERT advisory CA-96.01, at
    ftp://ftp.cert.org/pub/cert_advisories/CA-96.01.UDP_service_denial.
    To disable those particular services, comment out the lines which
    begin with their names in /etc/inetd.conf and 'killall -HUP inetd'.
    You may want to disable other unused UDP-based services as well.

  - Many devices have permissions which might allow a user to monitor
    another user via audio or video input, including

    /dev/audio
    /dev/dmrb
    /dev/hdsp/*
    /dev/vid
    /dev/video

    Bill Paul <wpaul@ctr.columbia.edu>'s solution is to add the
    following to /usr/lib/X11/xdm/Xstartup

    chmod 600 /dev/audio /dev/hdsp/* /dev/video /dev/vid /dev/dmrb
+   chown $USER /dev/audio /dev/hdsp/* /dev/video /dev/vid /dev/dmrb

    and the following to /usr/lib/X11/xdm/Xreset

    chmod 600 /dev/audio /dev/hdsp/* /dev/video /dev/vid /dev/dmrb
+   chown root /dev/audio /dev/hdsp/* /dev/video /dev/vid /dev/dmrb

+   (Simon ? <simon@instrumatic.ch> pointed out that the chmod should
+   precede the chown to avoid a race condition.)

  - Read the rest of the entries in this section and make the changes
    they describe if appropriate.

  Under IRIX 5.x or later only,

  - Turn on shadow passwords, which are not used by default. Run
    'pwconv' to move your passwords to /etc/shadow, where only root can
    read them. Note that you'll have to update /etc/shadow by hand for
    NIS users. See the pwconv(1M) and shadow(4) manpages.

! - Limit the hosts from which portmap(1M) and rpcbind(1M) will accept
!   RPC requests by using the -a option in /etc/config/portmap.options.
!   For example, if your machine is www.xxx.yyy.zzz and your subnet is
!   www.xxx.yyy you can reject RPC requests from outside your subnet by
!   putting '-a 255.255.255.0 www.xxx.yyy.0' in that file. Despite the
!   file's name and the absence of any options in the rpcbind manpage,
!   this appears to work with rpcbind as well as portmap. Note also the
!   related putative bug under "security-related bugs" below.

  This list is guaranteed to be incomplete. Keep your eyes open.
  Similar lists are in SGI's security advisory 19950401-01-I, which is
  at ftp://sgigate.sgi.com/Security/19950401-01-I, and a post by Dave
  Olson <olson@sgi.com>, a copy of which is at
  ftp://viz.tamu.edu/pub/sgi/software/security/olson-security.

------------------------------

Subject:    -4- How can I log more information about logins?
Date: 03 Feb 1996 00:00:01 EST

  - 'last', 'who', etc. get remote login information from
    /var/adm/utmpx and /var/adm/wtmp. That information is only logged
    into these files if they already exist. To create them, do
    'touch /var/adm/utmpx /var/adm/wtmpx'. The analogous files under
    IRIX 4.0.x are /etc/xutmp and /etc/xwtmp.

  - If you're running IRIX 5.3, install patch 420 to fix a bug which
    causes xterm(1) to log logins incorrectly.

  - As described in the login(1) manpage, you can add the line
    'syslog=all' to /etc/config/login.options (IRIX 4.0.x) or change the
    line 'SYSLOG=FAIL' in /etc/default/login to 'SYSLOG=ALL' (IRIX 5.x)
    to log all login attempts, not just successful ones, in
    /var/adm/SYSLOG. Under IRIX 5.x only, the same change in
    /etc/default/su has the same effect on 'su' attempts.

  - 'ftpd', 'rshd', 'tftpd' and 'fingerd' all have options ('-l' or
    '-L') which cause them to log all accesses. See their manpages.
    'ftpd' also has '-ll' and '-lll' options (undocumented before IRIX
    5.x) which log individual file transfers and the sizes of those
    files respectively.  Add the options to the last fields (not the
    second-to-last) of the appropriate lines of /etc/inetd.conf, then do
    'killall -HUP inetd' or reboot.

  - Consider using TCP wrappers. Besides logging, these allow you to
    restrict connections to individual TCP daemons to particular hosts
    and prevent some forms of address spoofing. You can get source code
    from ftp://ftp.win.tue.nl/pub/security/. Although the README.IRIX
    in current versions of the TCP wrappers package says that they do
    not work well with IRIX, they do in fact seem to work just fine.

------------------------------

Subject:    -5- How can I make an anonymous or restricted FTP account?
Date: 13 Aug 1995 00:00:01 EST

  Read the ftpd(1M) manpage and/or the article in the March/April 1994
  Pipeline. However, both discussions have a serious error: the ftp
  account's home directory (/usr/people/ftp) should be owned and
  writable only by root, NOT ftp. You might also want to make the 'pub'
  directory "sticky" with 'chmod +t' (like /tmp and /var/tmp) so that
  one user can't delete another's files. Two scripts which set up a
  secure or restricted anonymous FTP account are at
  ftp://viz.tamu.edu/pub/sgi/software/ftp/.

------------------------------

Subject:    -6- How can I get X authorization to work?
Date: 24 Feb 1996 00:00:01 EST

  Under IRIX 5.1.x or earlier, don't try. The MIT-MAGIC-COOKIE-1
  protocol did not work, and DGL programs did not understand X
! authorization.

  Under IRIX 5.2, heed the wise words of Mark Kilgard of SGI's
  X Window Systems group <mjk@hoot.asd.sgi.com>:

  The basic mechanism for the MIT-MAGIC-COOKIE-1 authorization protocol
  is implemented by the X server, Xlib, and xdm, and does work in IRIX
  5.x.  MIT-MAGIC-COOKIE-1 is the only supported protocol.

  Two caveats before I describe how to enable X authorization:

! 1) Old remote IRIS GL programs probably will not be able to connect to
!    the X server when X authorization is enabled. (More on this below.)

  2) Due to a problem with how the local hostname is handled, to use X
!    authorization in the IRIX 5.x releases, you will need to make sure
     your /etc/sys_id file has a simple hostname, ie. hoot instead of a
     fully resolved hostname like hoot.asd.sgi.com  This problem has
     already been fixed for the next general release of IRIX.

  TO ENABLE X AUTHORIZATION, do the following to your IRIX 5.2 system:

      1)  Edit /var/X11/xdm/xdm-config as root and change the line
      saying

  DisplayManager*authorize:               off

        to say

  DisplayManager*authorize:               on

      2) Edit /var/X11/xdm/Xsession, /var/X11/xdm/Xsession-remote, and
. /var/X11/xdm/Xsession.dt as root and change the line saying

  /usr/bin/X11/xhost +

         to say

  #/usr/bin/X11/xhost +

         This disables the "xhost +" by commenting out the command.

      3) Make sure your /etc/sys_id file has no periods in it.  For
. example, change as root:

  hoot.asd.sgi.com

         to say

  hoot

      4) Reboot the machine OR restart a new xdm and X server.  This
. can be done as root with the following command:

  (/usr/gfx/stopgfx; killall xdm; /usr/gfx/startgfx) &

      5) Log in.  X authorization should be enabled.

  If you want to disable X authorization and return to the default
  system state where X clients can connect to the X server from any
  machine, reverse the changes in steps 1 and 2 and repeat step 4.

  If you want more information on X authorization, see the manpages for
  xdm(1), Xserver(1), Xsgi(1), Xsecurity(1), xauth(1) and xhost(1).

! X AUTHORIZATION AND REMOTE IRIS GL PROGRAMS: One of the major reaons
! for Silicon Graphics shipping its window system so that an X client
! from any machine could connect to the X server was because IRIS GL
! programs running remote using the DGL (distributed GL) protocol didn't
! interoperate with the X authorization mechanism; the dgld daemon that
! would run on the machine with graphics hardware had no way to get the
! correct X authorization information to connect to the X server.

  This has been fixed for IRIX 5.2, but the fix only applies to IRIX 5
  binaries running remotely on an IRIX 5.2 system connecting to an IRIX
  5.2 X server.  In particular, remotely run IRIX 4 IRIS GL binaries
  will continue to not interoperate with an IRIX 5.2 X server (or a
  pre-IRIX 5.2 X server).  If you recompile your old IRIS GL binaries
  on IRIX 5.2, they then will work remotely connecting to IRIX 5.2 X
! servers running X authorization.

  The bottom line is that if you want an IRIS GL program to run
  remotely on an X server using X authorization, you need to make sure
  the program is an IRIX 5 binary running on an IRIX 5.2 machine and
  the machine with the X server is also an IRIX 5.2 machine.

  To avoid a possible misconception: IRIS GL programs RUNNING LOCALLY
  (ie, not using DGL) WILL WORK FINE on an IRIX 5.2 system no matter if
! they are IRIX 4 or IRIX 5 binaries. The problem with X authorization
! is only for REMOTE IRIS GL programs.

  Also note that for X authorization to work for remote hosts, the
  remote program must have access to the correct X authorization magic
  cookie (normally read from ~/.Xauthority).  If you don't have a
  shared NFS mounted home directory, you'll probably need to use the
  xauth command to transfer the X authorization magic cookie to the
  remote ~/.Xauthority file.

  THE FUTURE:  Hopefully in the next general release of IRIX, a
  mechanism to enable and disable X authorization using a chkconfig
  option will be supported.  The problem with /etc/sys_id not having
  periods will definitely be fixed in the next general release of
  IRIX.  The problem with pre-IRIX 5.2 X servers and binaries not
  interoperating with X authorization will likely not be fixed. Fixing
  the problem required a DGL protocol extension which both the IRIS GL
  program and dgld must know about; this can't be fixed in already
  shipped software.

  Under IRIX 5.3, do what you did for IRIX 5.2. There is no chkconfig
! option for X authorization. The problem with periods in hostnames is
! still present in 5.3 as such, but is fixed by patch 518. There is a
! bug in NFS3 which truncates ~/.Xauthority files which is fixed by
! patch 216. See also the descriptions of the shared memory hole and the
! putative X authorization weaknesses below under "security-related
! bugs".

------------------------------

Subject: !  -7- What security-related bugs does IRIX have?
Date: 31 Mar 1996 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.

  - CERT advisory CA-95:17, at

      ftp://ftp.cert.org/pub/cert_advisories/CA-95%3A17.rpc.ypupdated.vul

    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.

  - 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 1146.

    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.

  - SGI advisory 19960101-01-PX, at

      ftp://sgigate.sgi.com/Security/19960101-01-PX

    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.

  - SGI advisory 19960301-01-P, at

      ftp://sgigate.sgi.com/Security/19960301-01-P

    describes a hole in rpc.statd which allows a remote user to mount
    denial-of-service attacks or remove files. Patch 1145 to IRIX 5.2
!   and patch 1128 to IRIX 5.3, 6.0 and 6.0.1 close the hole. There is
!   no patch for IRIX 6.1.

! - 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.

+ These bugs have not yet been fixed:

  - /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.

  - 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 1146 prevents sendmail from passing
    dangerous data to syslog(3) in the first place, which prevents
    exploitation of the hole via sendmail only.

  - SGI advisory 19960102-01-P, at

      ftp://sgigate.sgi.com/Security/19960102-01-P

    describes a hole in /usr/pkg/bin/pkgadjust (part of the SVR4 pkg
    system, in eoe2.sw.oampkg, not installed by default) 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.

  - /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.

+ - gr_osview(1) can hang a system when certain pathological options
+   are placed in ~/.grosview. The bug is present in IRIX 5.3 and
+   thus probably in all IRIXes before 6.2; it is fixed in 6.2. You
+   could 'chmod 700' it to prevent mischief.

+ These bugs might be present in IRIX, but we don't yet know for sure:

+ - 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.

+ - CERT Advisory CA-94:15, at

+     ftp://ftp.cert.org/pub/cert_advisories/CA-94%3A15.NFS.Vulnerabilities

+   describes a bug in portmap(1M) and rpcbind(1M) which permits
+   unauthorized hosts to access exported filesystems. It may or may not
+   be present in IRIX. The recommendation under "How can I configure
+   IRIX to be more secure?" (q.v.) would prevent exploitation of this
+   bug from some hosts, but not all.

  - CERT Vendor-Initiated Bulletin VB-95:08, at

      ftp://ftp.cert.org/pub/cert_bulletins/VB-95%3A08.X_Authentication_Vul

    describes weaknesses in the MIT-MAGIC-COOKIE-1 and
    XDM-AUTHORIZATION-1 X-windows authorization schemes which may allow
    an otherwise unprivileged remote user to connect to an X display.
    These weaknesses are present in all X11 sample implementations up to
!   the release of the advisory, so *may* be present in IRIX. See also
!   the lengthy discussion of X authorization and the description of the
!   shared memory bug above.

  - CERT Advisory CA-96.02, at

      ftp://ftp.cert.org/pub/cert_advisories/CA-96.02.bind

    describes security fixes to version 4.9.3 of bind (including named
    and name resolution routines) which are not present in older
    versions or, software (such as the corresponding parts of IRIX)
    derived from older versions. SGI has only acknowledged the advisory
    so far.

------------------------------

Subject:    -8- I think I've found a security hole in IRIX; whom should
                I notify?
Date: 31 May 1995 00:00:01 EST

  First, call the TAC as for any bug.  Next, send email to
  security-alert@sgi.com.  You can also notify CERT <cert@cert.org>, who
  will contact the appropriate people from their contact list. They may
  take some time.

------------------------------

Subject:    -9- How can I get around the root and/or PROM passwords?
Date: 28 Nov 1995 00:00:01 EST

  To get around the root password, boot from an IRIX CD or tape as you
  would if you wanted to install software. (If you've set a PROM
  password, you'll need to provide it or circumvent it first; see
  below.) Say 'admin shroot' to get a root shell. You can then do any of
  the following:

  - use 'passwd' to change root's password
  - 'setenv TERM iris-tp' and 'vi/etc/passwd'
  - if /etc/passwd is really hosed, 'mv' the remains out of the way and
    'echo root::0:0:root:/:/bin/sh > /etc/passwd'.

  Alternatively, if your machine is an NIS client you can change the uid
  of an NIS account to 0 from the server and do a 'ypmake'.

  If you've lost your PROM password but can still log in as root, you
  can zero the PROM password with 'nvram passwd_key ""'. If not, you'll
  have to disable the PROM password via the hardware. On a 4D/35 or
  Crimson, find the battery which maintains the nvram ("non-volatile
  RAM") and remove it. On an Indigo or Indy, find the nvram chip itself
  and remove it. On an Indigo^2, remove the jumper described in the
  owner's manual. This may be a good time to call SGI.

------------------------------

Subject:   -10- What firewalls are available on SGI/IRIX platforms?
Date: 16 Mar 1996 00:00:01 EST

  Ping Huang <pshuang@sgi.com> writes:

  SGI is an OEM for Gauntlet (from Trusted Information Systems), meaning
  that SGI sells and supports Gauntlet directly. See
  http://www.tis.com/docs/Products/gauntlet.html for general Gauntlet
  product information. See your SGI sales person for specific
  information about Gauntlet for IRIX.

  I believe that is the only commercial firewall product currently
  available, although there are freely distributable (but unsupported
  and possibly dated) alternatives like the TIS Firewall Toolkit. If you
  want more choices, please make your desires for availability on the
  SGI/IRIX platform known to your favorite firewall vendor(s).

------------------------------

End of sgi/faq/security Digest
******************************
-- 
The SGI FAQ group <sgi-faq@viz.tamu.edu>   http://www-viz.tamu.edu/~sgi-faq/
Finger us for info on the SGI FAQs, or look in ftp://viz.tamu.edu/pub/sgi/.
