-------------------------------------------------------------------------
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 +" where
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 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
_______________________________________________________________________