Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!

TUCoPS :: HP/UX :: ciacf019.txt

HP-UX Satan

                       The U.S. Department of Energy
                    Computer Incident Advisory Capability
                           ___  __ __    _     ___
                          /       |     /_\   /
                          \___  __|__  /   \  \___

                             INFORMATION BULLETIN

		         Protecting HP-UX Systems Against SATAN

April 4, 1995 1600 PST					            Number F-19

PROBLEM:       SATAN, a tool for scanning Unix systems is scheduled to
               be released on April 5.  The tools identifies exploitable 
               vulnerabilities; most of which can be patched.
PLATFORM:      This bulletins focuses on SATAN's impact on  HP-UX 
DAMAGE:        Anyone running SATAN can gain vulnerability information
               that can be exploited with other tools to gain privileged
SOLUTION:      Update all HP-UX systems with the patches identified
AVAILABILITY:  All patches are available now.

VULNERABILITY   When SATAN is released via the Internet on April 5,
ASSESSMENT:     it will be available to anyone, including system 
                administrators and security specialists who protect
                corporate systems.  It will also be 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 

          CRITICAL Information for patching HP-UX Vulnerabilities

CIAC has obtained information from Hewlett Packard describing the 
specific patches for the vulnerabilities SATAN will scan for.  Specific 
patch details are provided below.

[Begin HP Bulletin]
******** 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 
PLATFORM: All HP-UX systems
ACTIONS:  Install portmap patches specified below, and consider advice
          discussed below.

ISSUE #1: Portmap permits forwarding of requests. 
DAMAGE :  Remote users can gain unauthorized access to exported file 

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: 
          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
HP-UX Security Response Team

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 



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 

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 

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 

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 

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 

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 problemThe 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 

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/ 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 

#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 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 

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") 

J. Vulnerability in rusersd configuration 

1. The problem

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

#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 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 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 (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 

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: (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 

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


V. To report new security vulnerabilities, send email to


[End HP Bulletin]


CIAC is the computer security incident response team for the U.S. 
Department of Energy. Services are available free of charge to DOE and 
DOE contractors.

For emergencies and off-hour assistance, DOE and DOE contractor sites 
can contact CIAC 24-hours a day via an integrated voicemail and SKYPAGE 
number. To use this service, dial 1-510-422-8193 or 1-800-759-7243 
(SKYPAGE). The primary SKYPAGE PIN number, 8550070 is for the CIAC duty 
person. A second PIN, 8550074 is for the CIAC Project Leader. CIAC's FAX 
number is 510-423-8002, and the STU-III number is 510-423-2604. Send E-
mail to

Previous CIAC notices, anti-virus software, and other information are 
available on the CIAC Bulletin Board and the CIAC Anonymous FTP server. 
The CIAC Bulletin Board is accessed at 1200 or 2400 baud at 510-423-4753 
and 9600 baud at 510-423-3331. The CIAC Anonymous FTP server 
is available on the Internet at (IP address

CIAC has several self-subscribing mailing lists for electronic 
subscribe (add yourself) to one of our mailing lists, send requests of 
the following form to

	subscribe list-name  LastName, FirstName PhoneNumber

For additional information or assistance, please contact CIAC:
    Voice:   510-422-8193
    FAX:     510-423-8002
    STU-III: 510-423-2604

ATTENTION!! CIAC now has a web server at


This document was prepared as an account of work sponsored by an agency 
of the United States Government. Neither the United States Government 
nor the University of California nor any of their employees, makes any 
warranty, express or implied, or assumes any legal liability or 
responsibility for the accuracy, completeness, or usefulness of any 
information, apparatus, product, or process disclosed, or represents 
that its use would not infringe privately owned rights. Reference herein 
to any specific commercial products, process, or service by trade name, 
trademark, manufacturer, or otherwise, does not necessarily constitute 
or imply its endorsement, recommendation or favoring by the United 
States Government or the University of California. The views and 
opinions of authors expressed herein do not necessarily state or reflect 
those of the United States Government or the University of California, 
and shall not be used for advertising or product endorsement purposes.

CIAC BULLETINS ISSUED IN FY95 (Previous bulletins available from CIAC)
(F-01)	SGI IRIX serial_ports Vulnerability
(F-02)	Summary of HP Security Bulletins
(F-03)	Restricted Distribution
(F-04)	Security Vulnerabilities in DECnet/OSI for OpenVMS
(F-05)	SCO Unix at, login, prwarn, sadc, and pt_chmod Patches
(F-06)	Novell UnixWare sadc, urestore, and suid_exec Vulnerabilities
(F-07)	New and Revised HP Bulletins
(F-08)	Internet Address Spoofing and Hijacked Session Attacks
(F-09)	Unix /bin/mail Vulnerabilities
(F-10)	HP-UX Remote Watch
(F-11)	Unix NCSA httpd Vulnerability
(F-12)	Kerberos Telnet Encryption Vulnerability
(F-13)	Unix sendmail vulnerabilities
(F-14)	HP-UX Malicious Code Sequences
(F-15)	HP-UX ‘at’ and ‘cron’ vulnerabilities
(F-16)	SGI IRIX Desktop Permissions Tool Vulnerability
(F-17)	Cray TCP/IP Sequence Number Spoofing
(F-18)	MPE/iX Vulnerabilities
(F-19)	 Protecting HP-UX Systems Against SATAN	

CIAC NOTES ISSUED IN FY1995 (Previous Notes available from CIAC)
04c	December 8, 1994
05d	January 11, 1995
06	March 22, 1995
07	March 29, 1995
08	April 4, 1995

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2015 AOH