AIX vs. SATAN - prepare your AIX system

AIX vs. SATAN - prepare your AIX system

Post by r.. » Tue, 11 Apr 1995 04:00:00



...........................................................................
                Preparing your AIX System for SATAN
                        AIX Security Response Team
                        secur...@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 ...

read more »

 
 
 

AIX vs. SATAN - prepare your AIX system

Post by Greg Pfist » Tue, 11 Apr 1995 04:00:00


I won't "include" the whole thing again -- the point is the title.

Should we "prepare" our systems because somebody is going to turn SATAN loose
on them at some point, as a test of security?

I don't think this is necessarily a bad idea.  I just want to know what's
coming down the pike.

Greg
--
------------------------------------------------------------------------
Greg Pfister                     |   My    | Sic Biscutus Disintegrandum

    VNET: PFISTER AT AUSTIN      |  only   |         Fax: (512) 838-2640

 
 
 

AIX vs. SATAN - prepare your AIX system

Post by Dale Shuttlewor » Tue, 11 Apr 1995 04:00:00


Hi,

: I won't "include" the whole thing again -- the point is the title.

: Should we "prepare" our systems because somebody is going to turn SATAN loose
: on them at some point, as a test of security?

: I don't think this is necessarily a bad idea.  I just want to know what's
: coming down the pike.

Well, if you value the data held on your computers, it would seem to be
a good idea to ensure that they are secure, unless you have absolute
faith in the security of IBMs firewall and the belief that no-one
within IBM has is likely to have a shot for the "fun" of it.

I would guess from the way your article is phrased that you didn't
expect your article to leave IBM.  Whilst not exactly a direct
security problem, its something to think about perhaps?

                Dale.

--
******************************************************************************
*  Dale Shuttleworth                                                         *

******************************************************************************

 
 
 

1. AIX 4.2 vs AIX 4.3

I just brought a used rs6k running aix 4.2.1. Is it a big different
between 4.2.1 to 4.3.2? I am thinking of upgrading the 4.2.1 to 4.3.2.
Is worth to upgrade or should I learn 4.2.1
Like Sun Solaris, out there still many sun boxex are running 2.6 instead
of Solaris 7 or 8. Or like novell 3.x or 4.x is running on more of the
business rather than 5.0 even it is lastest. Can anyone gimme comment!!

--
+--------------------------------------------------------+

|American Direct Mail(ADM) 350 Hudson Street, NY 11014   |
+--------------------------------------------------------+

Sent via Deja.com http://www.deja.com/
Before you buy.

2. Is there a AHA1742 driver ?

3. AIX smit Re: Solaris vs AIX

4. My PnP Modem Works :)

5. AIX 3.2.5 vs AIX 4.1

6. Passing parameter to PARM file of sqlloader dynamically from .ksh file

7. AIX 3.2 vs AIX 4.1 Implementation of Berkeley sockets

8. mknod expert needed

9. Malloc AIX 3.1 vs. AIX 3.2

10. AIX 4.2.1 vs AIX 4.3.1

11. Opinions Wanted: Solaris 2.4 vs. AIX vs. HP/UX vs AT&T Sys5v4

12. AIX SP2 - Where to look for AIX System Admin?

13. Preparing to Administer AIX