-----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 : Rene Ritzen                                 Index  :S-95-10.AIX
Distribution  : World                                       Page   :          1
Classification: External                                    Version:          1
Subject       : SATAN/SANTA specifics for IBM AIX           Date   :  14-Apr-95
===============================================================================

By courtesy of the AIX Security Response team we received the following 
information on how to prepare your AIX system for SATAN/SANTA .

In addition to this advisory we recommend you to read the CERT-NL
Security Advisories S-95-10, S-95-11 and S-95-12 : coordinates in the 
footer of this document.
 
===============================================================================
...........................................................................
    Preparing your AIX System for SATAN
      AIX Security Response Team
      security@austin.ibm.com
...........................................................................

I.   Purpose of this document
II.  AIX vulnerabilities probed by SATAN
   1.   NFS export to unprivileged programs
   2.   NFS export via portmapper
   3.   Unrestricted NFS export
   4.   NIS password file access
   5.   rexd access
   6.   Sendmail vulnerabilities
   7.   TFTP file access
   8.   Remote shell access
   9.   Unrestricted X server access
   10.  Writable FTP home directory
   11.  wu-ftpd vulnerability
III. More information on AIX security
IV.  More information on internet security topics

...........................................................................
I.   Purpose of this document
...........................................................................

Everyone is becoming increasingly aware of computer security
issues. No one wants to lose valuable information to unwanted
intruders. The SATAN tool was developed to help system administrators 
secure all computers on their networks. The danger exists that this 
tool could be used for unlawful purposes. 

We want to help AIX users secure their systems so SATAN will not 
cause any problems. This document is intended to help AIX users 
understand each of the vulnerabilities probed by SATAN and learn what 
they can do to secure their systems in each of these areas. Many 
books and articles have been written on computer security 
configuration issues and we will refer you to these articles 
when appropriate.

...........................................................................
II. AIX vulnerabilities probed by SATAN
...........................................................................

...........................................................................
   1.   NFS export to unprivileged programs
...........................................................................

If the nfs mount daemon, rpc.mountd, is started with the -n
flag it allows mount requests to come from non-privileged ports. 
This is used to allow some older versions of NFS to perform mounts.
It should not be used. The AIX default is to not use the -n flag.

For additional security use the nfso utility to turn on kernel port
checking. The command would be:
 nfso -o nfs_portmon=1 (in AIX version 3 )
 nfso -o portcheck=1   (in AIX version 4 )
The default in AIX is to NOT do kernel portchecking. 

...........................................................................
   2.   NFS export via portmapper
...........................................................................

Access to filesystems via portmapper is disabled by default in 
recent versions of AIX. To make sure you have a later version of
portmapper that fixes this problem, check to make sure your machine
has the fix for APAR IX32328. That fix has been included in PTFS
U419992 U419994 U419995. 

Use the following aix cmd to determine if you have applied these ptfs:
$ lslpp -al U419992 U419994 U419995

...........................................................................
   3.   Unrestricted NFS export
...........................................................................

Entering a directory or filesystem in the /etc/export list without
specifying an access list allows any host who's IP address can be 
resolved to mount the directory. This is not secure. The access list
should be specified when exporting filesystem objects.

Exports specifying root access or read/write access also are inherently
lower security and should be implemented with caution.

...........................................................................
   4.   NIS password file access
...........................................................................

The ability to view encrypted passwords when NIS is being used
and the ability to exploit the information can be curtailed and
to some extent prevented in a number of ways. 

A) use a /var/yp/securenets file to restrict the NIS services to 
trusted networks.  (see the notes on securenets below).

B) Make the NIS domain name hard to guess and non-obvious. Employee
turnover or other security concerns may require domain renaming. 
(use the chypdom command or smit chypdom to change domain names and
move the /var/yp/<domain_name> directory to the new name)

C) Require users to use non-trivial passwords. 


Use of the /var/yp/securenets file:

The implementation of ypserv and ypxfrd that utilize the
securenets file was shipped in response to APAR ix32328
Some PTF's that contain that fix are:
U419992 U419994 and U419995.

Use the following aix cmd to determine if you have applied these ptfs:
$ lslpp -al U419992 U419994 U419995

Both the "ypserv" and "ypxfrd" use a /var/yp/securenets
file and, if present, only responds to IP addresses in the
range given. This file is only read when the daemons (both
ypserv & ypxfrd) start. To get a change in /var/yp/securenets
to take effect, one must kill and restart the daemons.


The format of the file is one or more lines of:

netmask netaddr

e.g.

255.255.0.0 128.30.0.0
255.255.255.0 128.311.10.0

In the 2nd example, the netmask is 255.255.255.0
and the network address is 128.311.10.0 . This
setup will only allow the ypserv to respond to
those IP addresses which are within the subnet
128.311.10 range.

An additional NIS security note is that allowing ypset to
reset ypbind binding lowers security. ypbind daemons
shipped in the fix for APAR IX43595 (in PTF U431006)
disallow ypset's as their default behavior and this is
strongly recommended.

Use the following aix cmd to determine if you have applied this ptf:
$ lslpp -al U431006

...........................................................................
   5.   rexd access
...........................................................................

The rexd server allows users to execute commands on remote servers
in an environment similar to that of the local system.  No validation
of identity or access permission is performed.  This behavior leads
many people to believe that the use of rexd is a security vulnerability.

There are currently no known defects in the rpc.rexd command which
adversely affect the security of the system.  rpc.rexd is contained in
the bosnet.nfs.obj.client subsystem.  The most recent PTF for that
subsystem as of the writing of this document is U436781.

Use the following aix cmd to determine if you have applied this ptf:
$ lslpp -al U436781

The lack of authentication of the identity of the invoker may present
a security exposure in an untrustworthy environment.  You should weigh
the risks of a security exposure against the functionality provided when
you consider enabling this service.

The problems with rexd are inherent in the design of the server and
cannot be corrected easily.  The security problems can be limited by
careful use of NFS exports on the client system and by disabling rexd
on the server.

IBM issued CA-92:05 on March 5, 1992 describing a problem with the
initial configuration of rexd on AIX 3.1 and AIX 3.2 systems.  APAR
IX21353 was opened to correct this problem.  The problem corrected by
this APAR no longer exists in AIX 3.2.5 or AIX 4.1.

In AIX 3.2.5 and 4.1 rexd is disabled by default when shipped.

...........................................................................
   6.   Sendmail vulnerabilities
...........................................................................

All AIX versions of /usr/sbin/sendmail are vulnerable to some of the 
attacks described in CA-95:05. The official APARs resolving ALL known
AIX sendmail vulnerabilities are IX49257 (version 3.2) and IX49604 
(version 4.1).

AIX users should obtain the emergency patch from Internet
ftp site software.watson.ibm.com. The file is located in 
/pub/aix/sendmail/sendmail.tar.Z in compressed tar format. 
Please follow the installation instructions in the sendmail.readme
file located in this same directory.

Currently, AIX versions 3.2 and 4.1 are based on sendmail version
5.64. Although this is an old version of sendmail, all known
sendmail security bugs are fixed by the emergency patch mentioned
previously.
  
If you permit automatic mail forwarding or programs that accept
mail messages, please be sure there is no way for these programs
to create a shell or send commands. This type of configuration can
create a security hole that could be exploited by an unfriendly user.

...........................................................................
   7.   TFTP file access
...........................................................................

The tftpd server allows users to retrieve files without requiring an
account on the remote server.  Tftpd is commonly used by diskless systems
and X-stations as well.  Tftp does not require the use of a user name or
password and therefore may grant access to system data when the identity
of the requestor has not been established.  This may allow unknown users
to acquire restricted data or to modify user files.

There are currently no known defects in tftpd which adversely affect the
security of the system.  The tftpd command is contained in the
bosnet.tcpip.obj.client subsystem.  The most recent PTF for that subsystem
as of the writing of this document is U435114.

The lack of any authentication or identification of the requestor should
be considered when configuring tftpd.  The tftp service may be restricted
using the /etc/tftpaccess.ctl file.  This file is documented in
InfoExplorer under the tftpd command.  This function was added to AIX v3.1
by APAR IX22628 and is available in the 2014 level PTF.

Tftp should be configured in /etc/inetd.conf to run as the user "nobody".
The following line is an example of how to do this.

     tftp    dgram   udp     wait    nobody  /etc/tftpd tftpd -n

THIS EXAMPLE WILL ALLOW REMOTE USERS TO WRITE FILES ON THE LOCAL SYSTEM.
If you have no requirement for granting write permission to remote users
you should consider removing the "-n" flag from the command line given
above.

The user "nobody" should own no files or directories on the system.  The
only files or directories which the user "nobody" should be able to read
are those with read or write (and execute for directories) permission to
"other".  Refer to the chmod command in InfoExplorer for details on how to
manage file and directory permissions.  By properly restricting access to
"other", you will effectively limit the files and directories which tftpd
may access and modify.

IBM released CERT advisory CA:91-19 on October 17, 1991 for the tftpd
daemon.  The vulnerability described in that advisory is corrected in all
releases of AIX v3.2 and AIX v4.

...........................................................................
   8.   Remote shell access
...........................................................................

The rsh and rlogin commands are used to establish sessions on remote
servers.  Both commands operate in a similar manner from an access
perspective.  The file /etc/hosts.equiv or a .rhosts file in the user's
home directory may be consulted to determine if access is granted.  When
access is not automatically granted for the rlogin command the remote user
is prompted for a password.

The rshd server has had one security related defect.  APAR IX45182
corrected a defect in which the "-l" option (used to control operation of
the server) did not work properly.  This APAR was first delivered in PTF
U432655.  This PTF should be applied to any system which has been
configured according to the instructions given below.  This problem does 
not exist on any release of AIX v4.

The rlogind server has had one significant security related defect.  APARs
IX44254 and IX44367 corrected a defect in which any network user was able
to gain access to the remote system as any user.  These APARs were first
delivered in PTFs U431620 and U431622 respectively.  Both of these PTFs or
their superceding PTFs should be installed on all systems.  This problem
does not exist on any release of AIX v4.

Two significant enhancements have been made to the rshd server.  APAR
IX45701 added a facility for restricting use of rshd and rexecd on a user
by user basis.  This feature may be useful for critical system accounts
which might be subject to attack via a network connection.  This APAR was
first delivered in PTF U434068.  APAR IX48235 added additional auditing
capability.  This feature may be useful when connecting to unsecure
networks or when you are interested in monitoring rshd usage.  A USER_Login
audit event will be created for each rshd invocation.  This may be used in
conjunction with the TCPIP_access event to determine local user and remote
hostname for each rshd and rexecd.  As of the writing of this document this
APAR has not been packaged into a PTF.

Both rshd and rlogind are subject to security violations related to
use of the /etc/hosts.equiv and $HOME/.rhosts files.  This exposure can
be removed by adding the "-l" flag to the rshd and rlogind command
lines in /etc/inetd.conf.  The following two lines are an example of how
you might do this.

    shell    stream   tcp   nowait  root    /etc/rshd       rshd -l
    login    stream   tcp   nowait  root    /etc/rlogind    rlogind -l

If you do not wish to grant remote network access to your system, you may
disable this facility entirely with lines similar to the following.

    #shell    stream   tcp   nowait  root    /etc/rshd       rshd
    #login    stream   tcp   nowait  root    /etc/rlogind    rlogind

Please refer to InfoExplorer for additional information on configuring
the /etc/inetd.conf file and the inetd daemon.

Should you choose to enable rshd and/or rlogind, the use of the
/etc/hosts.equiv and $HOME/.rhosts files creates a dependency on the
information in those files and the information which the servers use being
accurate.  Errors in either file or spoofing of host addresses or names
are common causes of security exposures.  When the network is not secure
or trustworthy, consider disabling these services for some or all users or
enabling the auditing subsystem to track possible attacks.  You may also
wish to consider use of a firewall or some other form of packet filter to
restrict access to trustworthy hosts or networks.

InfoExplorer describes the proper configuration of the /etc/hosts.equiv
file.  As a general rule, grant access to specific users and specific
hosts.  You should monitor the existence of .rhosts files and insure that
users are educated about their proper use.

The telnet service may be more appropriate in an unsecured network
environment as it does not support the pre-authentication of users.

CERT advisory CA-94:09 was released on May 23, 1994 describing the security
exposure in the rlogin service.

Use the following aix cmd to determine if you have applied one of these ptfs:
$ lslpp -al U43xxxx

...........................................................................
   9.   Unrestricted X server access
...........................................................................

 In 1993 CERT  issued advisory CA-93:17 which documented a xterm vulnerability 
in X11R5 and earlier versions of X11. This problem was resolved by the 
following apars: 

   aixterm X11r4 : ix34738 - resolved by U417488 and U419246
   aixterm X11r5 : ix40275 - resolved by ptf U425631
   xterm   X11r4 : ix40279 - resolved by ptf U425255 and U425228
   xterm   X11r5 : resolved by U493250 (3.2.5 Gold)

Use the following aix cmd to determine if you have applied these ptfs:
$ lslpp -al U4xxxxx
   
  If you are using AIX 3.2, please make sure you have all these
ptfs applied to avoid potential security problems. These fixes
are shipped as part of the GOLD version of AIX 4.1.  Because of X11's design,
the client/server can be accessed by any other host on the network. If 
you are on the Internet, your display can be accessed by any machine in 
the world. X11 security issues for AIX are similar to the X11 security problems 
facing other X11 vendors. It is difficult to make X completely secure. 
However, there are access control mechanisms which can be put in place 
to help make your environment more secure. You should never use the
"xhost +" cmd because this will enable any remote user to read/write
screen information. Please remove all "xhost +" cmds from any file
or program on your system. A useful tool for limiting X access, please
see the /usr/bin/xauth 

The best source of information on securing X is in : O'Reilly & Associates,Inc.
"X Window System Adminstrator's Guide". Specifically chapter 4 which goes into 
detail about X security. The discussion in this chapter applies to the AIX 
environment.  In additon, the Common Desktop Enviroment (CDE) interface 
available on AIX 4.1 uses XDMCP protocol discussed in this chapter. 

...........................................................................
   10.  Writable FTP home directory
...........................................................................

In 1992, CERT issued advisory CA-92:09 about an AIX Anonymous FTP
Vulnerability. This problem was resolved by apar ix23944, which
was included in the GOLD release of AIX 3.2. Thus, AIX 3.2 and 4.1 systems
are not vulnerable to this problem. The original problem was discovered
on AIX 3.1. If you are running AIX 3.1, please update to the latest 
release of 3.1, which resolves this problem.

The following information can be very helpful:

- - -  The ftpd man page has explicit instructions for securely
   configuring your anonymous FTP user and subtree. 
- - -  The /usr/lpp/samples/tcpip/anon.ftp file can be used to securely 
   set up your anonymous account. (/usr/samples/tcpip/anon.ftp in AIX 4.1)
- - -  The CERT tip found at ftp://info.cert.org/tech_tips/anonymous_ftp
   contains applicable information.

...........................................................................
   11.  wu-ftpd vulnerability
...........................................................................

This problem only affects users running the wuarchive-ftpd.
If you do not have this modified version of ftpd, then you are
not vulnerable to this specific attack. If you are running the
wuarchive-ftpd, and your version is dated prior to April 8, 1993,
please take corrective action or remove this daemon.

You can obtain more information about this service via anonymous ftp 
from wuarchive.wustl.edu (128.252.135.4).

This service is NOT distributed with AIX.

...........................................................................
III. More information on AIX security
...........................................................................

  We publish an AIX security newsletter that is updated whenever
  we have security information that affects AIX users.

  To subscribe to the newsletter:

    mail -s "subscribe security" aixserv@austin.ibm.com < /dev/null
 
  If you have comments or questions about AIX security, or you
  would like to notify us of a potential problem, please send mail
  to security@austin.ibm.com.

  To order an APAR from IBM in the U.S. call 1-800-237-5511.
  APARs may be obtained outside the U.S. by contacting a 
  local IBM representative.
 
...........................................................................
IV.  More information on internet security topics
...........................................................................

   One of the best ftp sites for computer security information is
ftp://coast.cs.purdue.edu/pub. You might also want to check out
their WWW home page at http://www.cs.purdue.edu/coast. Their hotlist
of other security home pages is also very helpful.

  Other WWW sites with pointers to useful security info:
http://csrc.ncsl.nist.gov/first
http://ciac.llnl.gov

  There are many listservers and newsgroups that are completely
dedicated to the topic of computer security. You can find more
information about these by looking at some of the WWW sites mentioned
above.
==============================================================================
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/AwUBOL6IEjSYjBqwfc9jEQI5oQCg3g6rWdSZmW4+uPV4JafjOrWrExwAn1Nh
U/qD3uvPjfzf/4SqES940pYq
=jqTc
-----END PGP SIGNATURE-----