-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

===============================================================================
>>                                                      CERT-NL, 01-Mar-2000 <<
>> All CERT-NL information has been moved to http://cert.surfnet.nl.  Links  <<
>> to CERT-NL information contained in this advisory are therefore outdated. <<
>>                                                                           <<
>> CERT-NL also has stopped the CERT-CC-Mirror service.  Due to this the     <<
>> links to the CERT-CC mirror are obsolete. Visit the CERT-CC site for the  <<
>> complete CERT-CC advisory texts:                     http://www.cert.org  <<
===============================================================================
==============================================================================
Security Advisory                                                      CERT-NL
==============================================================================
Author/Source : CERT-NL (Don Stikvoort)                    Index  :    S-93-22
Distribution  : World                                      Page   :          1
Classification: External                                   Version:      Final
Subject       : SGI IRIX configuration vulnerabilities     Date   :  25-Oct-93
==============================================================================

CERT-NL received information about SGI IRIX configuration vulnerabilities.

The indication is that SGI IRIX systems configured with operating system 
defaults are vulnerable to attack.

We advise you to take appropriate actions.

In the below NASIRC (the NASA CERT) report all details are shown. 

We thank NASIRC for providing this information.

==============================================================================
==============================================================================


   NASIRC has received information indicating that SGI IRIX systems
   configured with operating system defaults are vulnerable to attack. The
   auto-installation procedure leaves some default accounts vulnerable to
   compromise, some files are left world readable, and the default
   configuration for xhost is vulnerable.  This bulletin reminds IRIX system
   administrators to check various default settings on their systems. 


OPEN ACCOUNTS

   Silicon Graphics IRIX machines come with several well-known
   vendor-supplied user IDs that have no password.  This means that anyone
   who guesses that your machine is an IRIX machine can attempt to login
   using one of these IDs. (Generally, using telnet to a machine will cause
   it to display its operating system type and version number.)  The IDs that
   have been seen in the local area are: 

      tutor        guest
      demos        lp
      uucp         nuucp
      4Dgifts      diag (may have superuser privileges)

   Because of the powerful graphical user interface, IRIX users may be
   unaware of the vulnerable IDs, or how to protect them.  Given any access
   to the system, attackers can usually find additional exposures that will
   allow them to gain superuser access.  In some cases, a non-privileged
   account such as guest has been used to copy any publicly readable file,
   such as the password file, /etc/passwd, to another machine.  The attacker
   then uses a password-cracking program to find additional accounts to
   exploit. 

   To find out if there are any IDs on your machine that have no password
   requirement, do the following: 

   1.    From the shell command line, enter:  grep :: /etc/passwd

   This will show you all user IDs that have a pair of colons, or a
   missing field, in the password file.  If the colons appear immediately
   after the name of the account, as in : 
   
      guest::1234:10:guest account:/usr/people/guest:/bin/csh

   Then the account has no password.

   2.    To close this hole, use jot or another editor to edit /etc/passwd.
   Change the "::" to ":*:", which locks the password.  This will prevent a
   user from directly logging into the account. 

   3.    To further protect the account, you should also change the shell
   field (the last field) from the usual value of "/bin/csh" to "/bin/false".
   This will prevent anyone from remotely logging into the account (using
   rlogin). The final entry would read: 

      guest:*:1234:10:guest account:/usr/people/guest:/bin/false

   4.    If the /etc/passwd file is publicly readable on your system, and you
   did have accounts with no password, you should assume that your password
   file has been compromised.  Once the accounts have been secured, you
   should then change all the passwords on the live user accounts. 
   Attachment A provides guidance on picking strong passwords.  You can
   change the passwords in two ways: 

    a)    Login to the system as root and issue the command

          passwd <username>
   
   Give the new passwords to the users and insist that they change them,
   using the password guidelines in Attachment A. 

   b)    Contact your users by telephone and insist that they log on and
   change their passwords.  You can tell if they have done so by keeping a
   copy or printout of the password file in its original state and comparing
   the second field (the encrypted password field) with the new one.  If they
   do not change them in a day or two, lock the passwords and make them come
   to you to get access. 
   
   Do not simply expire the users' passwords.  If an intruder has access to
   your system, he or she could change the password and continue using your
   system. 


UNRESTRICTED TFTP 

   1.    Another problem that has been seen in SGI machines is unrestricted
   tftp. tftp (trivial file transfer) is a program that is used to boot
   diskless workstations.  It provides NO user authentication.  On the SGI
   machines, it can be restricted to a directory containing the boot
   programs.  If it is not restricted, any network user can tftp to the host
   machine and copy any publicly-readable file, such as /etc/passwd. 

   The configuration for tftp may be found in the file
   /usr/etc/inetd.conf. When running in "secure" (restricted) mode it will
   look like this: 

     tftp  dgram  udp   wait  guest  /usr/etc/tftpd  tftpd -s <directory>

   where <directory> is something like /usr/local/boot. In unrestricted mode
   the -s parameter will be missing.  One method of installing a CD ROM drive
   on an SGI for network access seems to encourage the installer to remove
   the restrictions.  Do not be misled - if you remove the restrictions, any
   publicly- readable file will be open to the network. 

   2.    Use the following command to search for programs that execute with
   the owner's privileges: 

      find / -perm -004000 -o -perm -002000 \) -type f -print

   Be especially suspicious of any that belong to root and are located in
   user directories. 


CHECKING SYSTEM FOR POSSIBLE BREAKINS 

   1.    To search for evidence that your system has been attacked, try the
   following: 

   a.    grep login /usr/adm/SYSLOG >> logins.lst

   This command will make a list of all the successful and unsuccessful
   logins on your system since the SYSLOG file was enabled.  The list will be
   stored in the file logins.lst. 

   b.    Scan logins.lst looking for any of the IDs that had null passwords. 
   In particular, try the IDs listed in the first paragraph.  Also look for
   logins from outside the local community, for example a university with
   which you do not normally have communications.  Report any suspicious
   evidence to your Center Computer Security Manager.  Be sure to keep both
   /usr/adm/SYSLOG and logins.lst. 
   
   2.    You can also scan /usr/adm/sulog to see which users have become
   superuser with the su command. 
   
   3.    The IRIX system has options that allow you to configure logging. 
   These are found in the file /etc/config/login.options.  Some examples: 

   syslog = all   records all login attempts, whether successful or not
         syslog = fail  records only login failures
         passwdreq      requires each user to have a password
         lastlog        when the user logs in, displays the last previous
                        login time


ADDITIONAL LOGIN.OPTIONS vulnerability

   Login.options is a file that contains some parameters for the system's
   login process.  By default, this file is world readable.  NASIRC
   recommends that you change the permissions to read only for root and group
   by executing the following command as root: 

     chmod /etc/config/login.options 640

   Note: the options "syslog=all" or "syslog=fail", set within login.options
   will not log any login attempts made through the SGI-supplied graphical
   login process Pandora.  In addition, the file where login attempts are
   kept, /usr/adm/SYSLOG, should also not be world readable. 

YELLOW PAGES - ALTERNATE PASSWORD FILE

   If you are using yellow pages (NIS) you can set up an alternate password
   file with any name and place it anywhere.  This password file can be set
   up to contain only accounts of users that log in remotely (no
   administrative accounts).  Use of this file will make the information in
   /etc/passwd useless to anyone who might break into your system and try to
   crack passwords. 
   
   To define the password file, open or create the file
   /etc/config/ypmaster.options, and create a line with the text: 

     PWFILE=/path/newpasswdfile.name 
   
   NOTE: the permissions to /etc/config/ypmaster.options should not allow
   world read of this file which contains the name and location of the
   alternate password file.  Also note that this feature is available because
   shadow password files are incompatible with YP. 


XHOST DEFAULT CONFIGURATION

   The system default configuration for xhost is "xhost +".  This means that
   any host on the same network can use X protocols to access this machine. 
   X has well known vulnerabilities and there are automated programs that can
   remotely gain unauthorized access using X.  NASIRC recommends that you
   either deny all access to all hosts through X or authorize only known,
   trustworthy specific machines. 
   
   To deny all X access to your system, use the command "xhost -". 
   
   To restrict X access to selected hosts follow these three steps: 
   
   a. create or edit the file "/etc/Xn.hosts" where 'n' is the display   
   number of the server on the local host, normally 0, as in   
   "/etc/x0.hosts". 
   
   To grant access to hosts "newhost.gov" and "secondhost.gov" and no   
   other hosts the file /etc/x0hosts will consist of: 

        +newhost.gov    +secondhost.gov 

   b. Search through all files in the directory /usr/lib/X11/xdm for   
   occurances of the command "xhost +" or "/usr/bin/X11/xhost+".  Remove or
   comment out all such lines.  For SGI IRIS these files are by default: 

     /usr/lib/X11/xdm/xsession
     /usr/lib/X11/xdm/xsession-remote
     /usr/lib/X11/xdm/xsession.0

   c. Inform users that any xhost commands should be removed or commented   
   out of user startup scripts, such as .cshrc, .login, .profile, etc. 
   
   To add an additional level of security to your X environment, NASIRC
   recommends the use of xauthority for host access control.  To set up
   xauthority, edit the file /usr/lib/X11/xdm/xdm-config by replacing the
   "off" with "on" in the following line: 

     DisplayManager*authorize:off

   After all changes are made, SGI recommends that you reboot your machine to
   ensure that all changes take effect, and change all passwords for all
   users' accounts that may have been compromised. 

   To ensure that X has been turned off for non-registered hosts, perform the
   following test commands from an invalid machine: 
   
     setenv DISPLAY yourhostname:0
     /usr/bin/X11/xterm
   
   If a message appears which refuses the connection, then you have
   configured your system correctly. 

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

 NASIRC ACKNOWLEDGES: Lee Snapp (Johnson Space Center), Emily Lonsford
    (Mitre Corporation/JSC), John Ray and Dave Gehrt (Ames Research Center), 
    and the DoE CIAC Team for for their investigations, analysis and
    coordination of the information contained in this bulletin. 


==============================================================================
==============================================================================
CERT-NL is the Computer Emergency Response Team for SURFnet customers. SURFnet
is the Dutch network for educational, research and related institutes. CERT-NL
is a member of the Forum of Incident Response and Security Teams (FIRST).

All CERT-NL material is available under:
  http://cert.surfnet.nl/

In case of computer or network security problems please contact your local
CERT/security-team or CERT-NL  (if your institute is NOT a SURFnet customer
please address the appropriate (local) CERT/security-team).

CERT-NL is one/two hour(s) ahead of UTC (GMT) in winter/summer,
i.e. UTC+0100 in winter and UTC+0200 in summer (DST).

   Email:     cert-nl@surfnet.nl     ATTENDED REGULARLY ALL DAYS
   Phone:     +31 302 305 305        BUSINESS HOURS ONLY
   Fax:       +31 302 305 329        BUSINESS HOURS ONLY
   Snailmail: SURFnet bv
              Attn. CERT-NL
              P.O. Box 19035
              NL - 3501 DA  UTRECHT
              The Netherlands

NOODGEVALLEN:    06 22 92 35 64      ALTIJD BEREIKBAAR
EMERGENCIES : +31 6 22 92 35 64      ATTENDED AT ALL TIMES
CERT-NL'S EMERGENCY PHONENUMBER IS ONLY TO BE USED IN CASE OF EMERGENCIES:
THE SURFNET HELPDESK OPERATING THE EMERGENCY NUMBER HAS A *FIXED*
PROCEDURE FOR DEALING WITH YOUR ALERT AND WILL IN REGULAR CASES RELAY IT
TO CERT-NL IN AN APPROPRIATE MANNER. CERT-NL WILL THEN CONTACT YOU.
===============================================================================

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1i

iQA/AwUBOL6WCjSYjBqwfc9jEQJK7QCgunjA0HXlJMukc/1IArkaLQjudGcAn08t
XviPsSkw0g6SMEZuAd5meoFu
=gvWk
-----END PGP SIGNATURE-----