[102] in Intrusion Detection Systems
CIAC Bulletin F-23 1 of 2
daemon@ATHENA.MIT.EDU (Frank Swift at Home)
Fri May 12 04:11:05 1995
Date: Thu, 11 May 1995 18:53:27 -0700
To: ids@uow.edu.au, academic-firewalls@net.tamu.edu, firewalls-uk@gbnet.net
From: uncl@llnl.gov (Frank Swift at Home)
Reply-To: ids@uow.edu.au
Date: Thu, 11 May 1995 13:14:19 -0700
Errors-To: listmanager@cheetah.llnl.gov
Reply-To: fisher@bill.llnl.gov
Originator: ciac-bulletin@cheetah.llnl.gov
Sender: ciac-bulletin@cheetah.llnl.gov
Precedence: bulk
From: fisher@bill.llnl.gov (John M. Fisher)
To: uncl@llnl.gov
Subject: CIAC Bulletin F-23
X-Listprocessor-Version: 6.0b -- ListProcessor by Anastasios Kotsikonas
________________________________________________________
The U.S. Department of Energy
Computer Incident Advisory Capability
___ __ __ _ ___
/ | /_\ /
\___ __|__ / \ \___
__________________________________________________________
INFORMATION BULLETIN
Protecting IBM AIX Systems Against SATAN
May 11, 1995 1100 PDT Number F-23
_____________________________________________________________________
PROBLEM: SATAN, a tool for scanning Unix systems was released on
April 5. The tools identifies exploitable vulnerabilities,
most of which can be patched.
PLATFORM: This bulletins focuses on SATAN's impact on IBM AIX
Systems.
DAMAGE: Anyone running SATAN can gain vulnerability information
that can be exploited with other tools to gain privileged
access.
SOLUTION: Update all IBM AIX systems with the patches identified
below.
AVAILABILITY: All patches are available now.
_____________________________________________________________________
VULNERABILITY When SATAN was released via the Internet on April 5, it
ASSESSMENT: became available to anyone, including system administrators
and security specialists who protect corporate systems.
It is also available to others who could use it to gain
information about unpatched system vulnerabilities and
then exploit these vulnerabilities with other tools to
gain unauthorized access.
_____________________________________________________________________
CRITICAL Information for patching IBM AIX Vulnerabilities
CIAC has obtained information from IBM describing the specific patches
for the vulnerabilities SATAN will scan for. Specific patch details
are provided below.
[BEGINNING OF IBM AIX BULLETIN]
..........................................................................
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
V. CERT advisory on SATAN
..........................................................................
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
Frank Swift L-321 (Sent from Home)
Unclassified Computer Security Coordinator
Lawrence Livermore National Laboratory (LLNL)
7000 East Avenue L-321 Livermore CA 94550-9516
Voice: (510) 422-1463 FAX: (510) 423-0913
