Docstoc

hp

Document Sample
hp Powered By Docstoc
					-------------------------------------------------------------------------
        HEWLETT-PACKARD SECURITY BULLETIN: #00026, 3 April 1995
                   ******** ADVISORY ONLY ********
-------------------------------------------------------------------------

Hewlett-Packard recommends that the information in the following
Security Bulletin should be acted upon as soon as possible. Hewlett-
Packard will not be liable for any consequences to any customer resulting
from customer's failure to fully implement instructions in this Security
Bulletin as soon as possible.


_______________________________________________________________________
ISSUE:    Release of SATAN program strengthens need for vigilant
          system administration.
PLATFORM: All HP-UX systems
ACTIONS: Install portmap patches specified below, and consider
          advice discussed below.

PATCHES:
--------
ISSUE #1: Portmap permits forwarding of requests.
DAMAGE : Remote users can gain unauthorized access to    exported file
          systems.
SOLUTION: Apply patch PHNE_4879 (series 700/800, HP-UX   9.x), or
                      PHNE_5081 (series 300/400, HP-UX   9.0), or
                      PHNE_5156 (series 300/400, HP-UX   8.x)
          For 700/800, HP-UX 8.x, disable portmap.

ISSUE #2: ENHANCEMENT FOR HP-UX 9.x: Strengthen NIS authentication.
          NIS client/server enhancement for access control lists:
          Apply patch PHNE_4958 (series 700/800, HP-UX 9.x), or
                      PHNE_5081 (series 300/400, HP-UX 9.x)

ISSUE #3: NTP should not be used as the time source for HP-DCE/9000
          until further notice.
PLATFORM: All HP-UX systems
DAMAGE:   HP-DCE/9000 could require reconfiguration and re-installation.
ACTIONS: Implement procedure discussed below before running SATAN.

_______________________________________________________________________


........................................................................
               Preparing Your HP-UX System for SATAN
                           Bob Kelley
                       bkelley@cup.hp.com
                  HP-UX Security Response Team


I. SATAN vs. HP-UX
   A. Writable FTP Home Directory
   B. Unprivileged NFS Access
   C. Unrestricted NFS Export
     D.   NIS Password File Access
     E.   Portmap Forwarding
     F.   TFTP File Access
     G.   Remote Shell Access
     H.   Vulnerability in rexd configuration
     I.   Sendmail Vulnerabilities
     J.   X Server Access
     K.   NTP vulnerabilities and HP-DCE/9000

II. Additional Advice on Network Security
   A. Fingerd
   B. Inetd and /usr/adm/inetd.sec
   C. Passwords
   D. Message Off
   E. Denial of Service Attacks
   F. IP Spoofing
   G. RIP Updates
   H. Controlling Root Access
   I. DNS Searchlist / RFC 1535
   J. Vulnerability in rusersd configuration

III.      HP-UX Patch Information

IV.    HP SupportLine and HP Security Bulletins

V.     Report vulnerabilities to security-alert@hp.com

........................................................................



I. SATAN vs. HP-UX

The Hewlett-Packard HP-UX Security Response Team has tested
beta version 0.50 of the Security Analysis Tool for Analyzing
Networks (SATAN). This advisory contains information
based on our review of this pre-release version. SATAN is
scheduled for release on April 5, 1995 at 14:00 GMT.

SATAN is a World Wide Web based tool that automates network
vulnerability testing and reporting. Documentation on SATAN can be
found at:

       ftp://ftp.win.tue.nl/pub/security/satan_doc.tar.Z

SATAN gathers information about hosts or networks by remotely
examining network services. It then generates a summary of the
potential vulnerabilities discovered on those hosts. In addition,
it offers a brief description of the vulnerabilities, and
possible workarounds to those vulnerabilities.   At this time,
SATAN does not actively use these vulnerabilities to break into
the examined hosts.

SATAN's construction provides a flexible framework for examining
network vulnerabilities and reporting test results. Each time
SATAN is run, tests can be aimed at a single host, hosts on
a network, or hosts connected to the target host. The testing
can expand exponentially to multiple "levels" away from the
target system or target network, adding many hosts to the list
of examined systems.

SATAN is quite extensible: perl scripts designed to examine
new network vulnerabilities can easily be added. Combining
this extensibility with the automation of quickly examining
many hosts allows SATAN to quickly discover vulnerable hosts.

The initial distribution of SATAN looks for about ten
vulnerabilities. As a result of publicity, it is likely
that additional tests will be added to SATAN. The first
part of this advisory deals with the initial ten vulnerabilities
that SATAN targets:


A. Writable FTP Home Directory

   The ftpd man page provides appropriate recommendations
   for the permissions and ownership of all the sub-directories,
   but erroneously recommends that the ~ftp home directory be
   owned by ftp. This allows an anonymous ftp user to change
   the permission on the ~ftp home directory, and control
   (read/modify/delete) any files owned by ftp in the
   ~ftp home directory.

   Make sure that the login shell of the ftp account is
   de-activated by putting a '*' in the password field of the
   /etc/passwd line, and referencing /bin/false as the login shell.

   Do not place a complete copy of /etc/passwd into
   ~ftp/etc to prevent distribution of the passwd file to
   hackers for cracking. Instead, put '*' into the
   password part of each account in the ~ftp/etc/passwd file.
   Also, try to remove any accounts from the ~ftp/etc/passwd file
   of users that will not be using ftp.


B. Unprivileged NFS Access

   1. The problem

   rpc.mountd is usually started from /etc/netnfsrc by setting
   START_MOUNTD=1. Starting rpc.mountd in this manner provides little
   confidence in the originator of the mount RPC request. An
   intruder could gain access to the exported file system. If you
   are concerned about the security of exported file systems,
   starting rpc.mountd from /etc/netnfsrc may be a vulnerability.

   2. Fixing the problem
   This vulnerability can be closed by only starting rpc.mountd
   from /etc/inetd.conf and using /usr/adm/inetd.sec to control
   which clients may have access to the rpc.mountd program.

   Uncomment (or add) the rpc.mountd line in /etc/inetd.conf:

rpc dgram udp wait root /usr/etc/rpc.mountd 100005 1 rpc.mountd -e

   The "-e" option causes rpc.mountd to exit after serving each
   RPC request, allowing inetd.sec to validate the authority of
   each RPC request.

   Be sure to start inetd with logging turned on (inetd -l) by
   modifying the /etc/netlinkrc line for inetd from:

[ -x /etc/inetd ]   &&   /etc/inetd   &&   /bin/echo "inetd   \c"

   to be:

[ -x /etc/inetd ]   &&   /etc/inetd -l &&    /bin/echo "inetd   \c"


   3. Limitations

   rpc.mountd handles each RPC request properly using inetd, as
   NFS is a stateless protocol that relies on RPC and UDP packets
   to deal with mount requests. However, showmount (1M) cannot
   be used when rpc.mountd is started from inetd since showmount
   uses TCP to get information from rpc.mountd and inetd only
   registers the udp port.


C. Unrestricted NFS Export

   Make sure all file exports specify an explicit list
   of clients or netgroups. Empty host fields in netgroups
   are treated as wildcards, allowing any host to gain
   access to the file system, so be very careful when
   using these wildcards.

   Avoid exporting file systems with write capability if
   possible. Avoid exporting file systems for root
   access if at all possible.


D. NIS Password File Access

   Make the NIS domain name a difficult one to guess,
   to prevent unauthorized ypbinds from binding to the
   server.   Enforce good password selection when using
   NIS to serve passwd maps, as it is quite likely that
   a hacker would be able to guess the domain name and
   get a copy of the /etc/passwd file to run a password
   cracker against.
   An enhancement to HP-UX 9.x added an access control list to NIS.
   The /etc/securenets file is used by both clients and servers.
   On the NIS server, this file lists networks and hosts which may
   access NIS maps from this server. On the NIS client, this file
   lists networks and hosts which may act as NIS servers when ypbind
   attempts to find a server.

   To add the /etc/securenets functionality, install these patches:

        9.x s700_800     PHNE_4879
        9.x s300_400     PHNE_5081


E. Portmap Forwarding

   This problem is fixed in most versions of HP-UX, when
   these patches are applied:

        9.x s700_800:    PHNE_4879
        9.x s300_400:    PHNE_5081
        8.x s300_400:    PHNE_5156

   Running portmap on a s700 or s800 with 8.x is vulnerable
   to this attack. If you are concerned with the security
   of such a system, disable portmap or upgrade to 9.x.


F. TFTP File Access

   HP's tftpd only allows access to the /usr/tftpdir directory
   and files in paths specified in the inetd.conf startup line.

   Be careful not to offer access to directories containing
   vital information (/, /etc, or others), since tftp offers
   minimal protection. (The initial startup of tftpd is controlled
   by inetd which can control access via inetd.sec; however,
   once tftpd is running, no further validation is done by
   tftpd on new requests.)

   Make sure files in /usr/tftpdir cannot be overwritten
   by user tftp by turning write permissions off.

   Make sure that the login shell of the tftp account is
   de-activated by putting a '*' in the password field of the
   /etc/passwd line, and referencing /bin/false as the login shell.


G. Remote Shell Access

   Using remsh (rsh), rlogin, or rcp permits a system to grant
   privileges without the user typing a password. In a secure
   environment, behind a properly configured firewall, these
   services can be helpful. Each user can create a .rhosts file
   to allow easy access to each host.

   However, if your hosts are connected to an unsecure network
   (say, the Internet), it is dangerous to grant privileges based
   on a hostname and an IP address: you should consider disabling
   these services by removing them from /etc/inetd.conf, or by
   commenting them out in /etc/inetd.conf:

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

   If you do decide to use them in an UNSECURE environment,
   consider using them WITHOUT .rhosts files, and WITHOUT
   a /etc/hosts.equiv file. As the super-user, you control
   the existance and contents of the /.rhosts and /etc/hosts.equiv
   files. Furthermore, you can use the "-l" options to enforce
   a policy of preventing users from using .rhosts files.

   The remote shell daemon (remshd(1M), known as rshd on non-HP-UX
   systems), offers a "-l" option to prevent authentication
   based on the user's .rhosts file unless the user is the
   super-user. Rlogind(1M) also offers a "-l" option. Both
   of these services are started from inetd, so you can add the
   "-l" option to their entries in /etc/inetd.conf:

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

   In HP-UX, "+::" in the /etc/passwd file indicates a switch
   to the NIS map. It will NOT allow a login as user "+", so you
   should NOT put "+:*:" in these files. In HP-UX, "+:*:" indicates
   that the NIS map should be consulted, but that all NIS accounts
   should be de-activated!

   A '+' in the /etc/hosts.equiv file is a wildcard that indicates
   that any remote host will be approved for access. So, do NOT
   put a '+' in /etc/hosts.equiv.

   A '+ +' in /.rhosts (or any .rhosts) indicates that any remote
   user is approved for access. So, do NOT put a '+ +' in the
   /.rhosts file or in any .rhosts file.

   For maximum security, do not list user names in /etc/hosts.equiv:
   only list system names.

   Finally, remember to only use .rhosts or hosts.equiv files in a
   trusted environment, behind a firewall.


H. Vulnerability in rexd configuration

   1. The problem

   The default setting for rexd in the /etc/inetd.conf file is
   as follows:

#rpc    stream tcp    nowait   root   /usr/etc/rpc.rexd   100017    1 rpc.rexd

   If you uncomment this line to enable rexd, an intruder can
   masquerade as a trusted system and trusted user.

   2. Fixing the problems

   This vulnerability can easily be closed by adding the -r option
   to the rpc.rexd entry in the /etc/inetd.conf file:

rpc    stream tcp    nowait    root   /usr/etc/rpc.rexd   100017   1 rpc.rexd -r

   Rexd should only be invoked with the "-r" option. This
   option specifies that only hosts listed in /etc/hosts.equiv
   are permitted to use the rexd.


I. Sendmail Vulnerabilities

   HP Security Bulletin #25 provides a list of the latest
   sendmail patches. By installing these patches, all
   known sendmail bugs are fixed. Even though SATAN
   tries to infer the status of sendmail by connecting
   to the SMTP port and reading the banner, this will not
   directly provide information on the patch level.

   Consider using site hiding in your /usr/lib/sendmail.cf file
   (the DY macro) to hide system names inside your network.


J. X Server Access

   Users should not run with "xhost +", as this permits access
   to the X server from arbitrary hosts. A better level of
   protection is provided by at least specifying hosts which
   are permitted access by using "xhost +<hostname>" where
   <hostname> is the name of a host.

   Client-side authentication is also available in the
   xauth authority file utility, which uses the MIT-MAGIC-
   COOKIE-1 protocol.


K. NTP vulnerabilities and HP-DCE/9000

   1. The Problem

   When Satan   is run to analyze the vulnerabilities of an HP-UX system
   whose time   is synchronized by NTP, the time of the system can be set
   forward by   several years. This vulnerability can affect DCE cells
that
   use NTP as   a time source, either with the dts_ntp_provider or with the
   dts_null_provider running on an NTP client. In this event, the Cell
   Directory Service (CDS) can become locked at this future date,
   rendering the DCE cell inoperable.

   2. Fixing the Problem

   Hewlett-Packard recommends you configure your HP-DCE/9000 systems to
   use either the dts_spectracom_provider or to use the dts_null_provider
   without NTP. Further information on how to use NTP in conjunction
   with DTS is available from your HP support contact.


........................................................................

II. Additional Advice on Network Security

SATAN is quite extensible, so it is probable that these
issues will become important during the impending
growth of the program.


A. Fingerd

   Running fingerd can allow outsiders to find login names
   (finger @system.domain), helping them to build up information on
   users.

   1. The problem

   The default setting for fingerd in the /etc/inetd.conf file is
   as follows:

#finger           stream tcp nowait bin /etc/fingerd   fingerd

   If you uncomment this line to enable fingerd, an intruder can
   use this program to discover user information on your system.

   2. Fixing the problem

   This vulnerability can easily be closed by adding access control
   to /usr/adm/inetd.sec for this service, such as the following line:

finger    allow    10.3-5 192.34.56.5 ahost anetwork


B. Inetd and /usr/adm/inetd.sec

   The two important functions of a TCP wrapper program are
   connection logging and access control.

   1. /usr/adm/inetd.sec

   Use inetd.sec to list which outside hosts and networks are
   permitted to use services.
   When inetd accepts a connection from a remote system, it checks the
   address of the host requesting the service against the list of hosts
   to be allowed or denied access to the specific service (see
   inetd(1M)). The file inetd.sec allows the system administrator to
   control which hosts (or networks in general) are allowed to use the
   system remotely. This file constitutes an extra layer of security in
   addition to the normal checks done by the services. It precedes the
   security of the servers; that is, a server is not started by the
   Internet daemon unless the host requesting the service is a valid host
   according to inetd.sec.

   2. Inetd logging

   Be sure to start inetd with logging turned on (inetd -l) by
   modifying the /etc/netlinkrc line for inetd from:

[ -x /etc/inetd ]   &&   /etc/inetd   &&   /bin/echo "inetd   \c"

   to be:

[ -x /etc/inetd ]   &&   /etc/inetd -l &&    /bin/echo "inetd   \c"


C. Passwords

   If you ftp or telnet or rlogin across an insecure network,
   your password has traveled cleartext across networks which
   might be traced by sniffers. Change your password as soon as
   possible.


D. Message Off

   Execute 'mesg n' in each user's shell rc script (.kshrc,
   .cshrc, or .shrc, etc) to turn off each shell from being
   world writable.


E. Denial of Service Attacks

   Denial of service attacks are always possible: the best way
   to deal with this is to react to intrusions by adding intruder
   source hosts/networks into the DENY listings in the inetd.sec.
   There is no proactive way to avoid this without disabling
   networking altogether.


F. IP Spoofing

   Many of the above attacks can be combined with IP spoofing
   to allow false IP authentication to occur. Configure firewall
   routers to prevent externally initiated connections, as
   described in the recent CERT bulletin (CA-95:01).
G. RIP Updates

   Gated can be configured to only listen to routing updates
   from trusted gateways on all versions of HP-UX. By default,
   gated would listen to routing updates from any source; this
   offers the potential for abuse.

   1. HP-UX 8.x: Gated 1.9
      Gated.conf can be modified to permit only certain
      sources of routing information:

      trustedripgateways gateway [ gateway ] ...
      trustedhellogateways gateway [ gateway ] ...

      When these clauses are specified, gated will only listen to
      RIP or HELLO information respectively from these RIP or
      HELLO gateways.

   2. HP-UX 9.x:   Gated 2.1

      Gated.conf can also be modified to permit certain sources of
      routing information. For distance vector IGPs (RIP and HELLO)
      and redirects (ICMP), the trustedgateways clause supplies a list
      of gateways providing valid routing information; routing packets
      from others are ignored. This defaults to all gateways on the
      attached networks.

   See the man page on your system for more details.


H. Controlling Root Access

   The file /etc/securetty can be used to control who can
   login to a system as root. By creating a file of this name
   containing the text "console", users of the system can only
   login as root by being at the console of the machine.
   See the man page for login(1) for more details.


I. DNS Searchlist / RFC 1535

   By default, a hostname lookup using the DNS resolver will
   proceed by appending the current domain to the hostname,
   attempting a lookup, and on failure, remove the leftmost
   part of the current domain, and retry. RFC 1535 mentions
   that there are possible attacks on this approach. All
   current versions of HP-UX use this behavior as default.

   This behavior can be modified by using a "search" keyword
   in the /etc/resolv.conf file to specify the exact domain
   search procedure. (such as "search cup.hp.com hp.com")
J. Vulnerability in rusersd configuration

   1. The problem

   The default setting for rusersd in the /etc/inetd.conf file is
   as follows:

#rpc dgram udp wait root /usr/etc/rpc.rusersd 100002 1-2 rpc.rusersd

   If you uncomment this line to enable rusersd, an intruder can
   use this program to discover user account names on your system.
   Although this information is of marginal significance, it does
   add to the intruder's list of information about your system.

   2. Fixing the problem

   This vulnerability can easily be closed by adding access control
   to inetd.sec for this service, such as the following line:

ruserd      allow   10.3-5 192.34.56.5 ahost anetwork

   Then modify the inetd.conf line to add the "-e" option. This
   option causes the rpc.rusersd program to exit after serving
   each RPC request.

rpc dgram udp wait root /usr/etc/rpc.rusersd 100002 1-2 rpc.rusersd -e


K. Bootpd

   1. The problem

   A bootp request from a client is sent to an inetd server which
   returns information on a boot file. Although this information is
   of marginal significance, it does add to the intruder's list of
   information about your system.

   2. Fixing the problem

   The exposure to this vulnerability can be minimized by only starting
   bootpd from inetd (and NOT as a standalone program from /etc/netbsdsrc
   with the "-s" option) and using /usr/adm/inetd.sec to control access
   to this service. Adding a line such as:

bootps      allow   10.3-5 192.34.56.5 ahost anetwork

   to /usr/adm/inetd.sec will only allow the specified hosts and networks
   to make bootp requests.

   Then modify the inetd.conf line to add a small timeout, say
   one minute. This means that after a client has made a bootp
   request, the bootpd will exit after one minute. Modify the
   /etc/inetd.conf line to add the -t<timeout in minutes> option:
bootps        dgram   udp wait    root /etc/bootpd   bootpd -t1




........................................................................

III.    HP-UX Patch Information

   Hewlett-Packard recommends that all customers concerned with the
   security of their HP-UX systems apply the appropriate patches or
   perform the actions described above as soon as possible.

   Since the first HP Security Bulletin in November, 1993, Hewlett-
   Packard has issued 25 HP-UX security bulletins. A patch matrix
   showing all the patches referenced in these bulletins is available
   from HPSL (see instructions in Section IV.) In addition to
   these patches, a number of other patches related to security were
   released before November 1993. Customers are advised to consult
   the patch catalog and install all applicable patches (security
   and otherwise) to ensure that their systems are protected. If
   this is not possible, customers should consider upgrading to the
   latest current HP-UX release.

   How to Install the Patches (for HP-UX 8.x and 9.y)

   1.    Determine which patch is appropriate for your hardware platform
         and operating system, as mentioned above.

   2.    Hewlett Packard's HP-UX patches are available via email
         and World Wide Web

         To obtain a copy of the HP SupportLine email service user's guide,
         send the following in the TEXT PORTION OF THE MESSAGE to
         support@support.mayfield.hp.com (no Subject is required):

                  send guide

       The user's guide explains the process for downloading HP-UX
patches
       via email and other services available.

         World Wide Web service for downloading of patches is available
         via our URL:

                  http://support.mayfield.hp.com


   3.    Apply the patch to your HP-UX system.

   4.    Examine /tmp/update.log for any relevant WARNINGs or ERRORs.     This
         can be done as follows:
       a.   At the shell prompt, type "tail -60 /tmp/update.log | more"
       b.   Page through the next three screens via the space bar, looking
            for WARNING or ERROR messages.


........................................................................

IV.   HP SupportLine and HP Security Bulletins

      To subscribe to automatically receive future NEW HP Security
      Bulletins from the HP SupportLine mail service via electronic
      mail, send an email message to:

         support@support.mayfield.hp.com     (no Subject is required)

      Multiple instructions are allowed in the TEXT PORTION OF THE
      MESSAGE. Here are some basic instructions you may want to use:

      To add your name to the subscription list for new security
      bulletins, send the following in the TEXT PORTION OF THE MESSAGE:

                   subscribe security_info

      To retrieve the index of all HP Security Bulletins issued to date,
      send the following in the TEXT PORTION OF THE MESSAGE:

                   send security_info_list

      To get a patch matrix of current HP-UX and BLS security
      patches referenced by either Security Bulletin or Platform/OS,
      put the following in the text portion of your message:

                   send hp-ux_patch_matrix

      World Wide Web service for browsing of bulletins
      is available via our URL:

                   http://support.mayfield.hp.com

      Choose "Support news", then under Support news,
      choose "Security Bulletins"


........................................................................

V.    To report new security vulnerabilities, send email to

                   security-alert@hp.com

_______________________________________________________________________

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:29
posted:11/5/2011
language:English
pages:13