HP-UX SPECIFIC SECURITY CONCERNS
by Paul Taffel, VESOFT
Presented at SCRUG (Southern California Regional User Group)
1993 Meeting, Burbank, CA, USA
Overview
--------
This paper is NOT intended to cover all UNIX security issues, rather I'll
try to highlight some of the significant issues that need to be addressed
when trying to secure your system, and then comment on peculiarities of
HP's UNIX implementation. There are enough areas where HP-UX differs from
other UNIX implementations in the areas of security to warrant this
discussion.
In general, do NOT assume that if you've closed the loopholes described
here, that your system is secure. It won't be. If you are responsible
for controlling access to your UNIX system, you should obtain some of the
excellent UNIX security books available (see references section), and
preferably both obtain and regularly use a security auditing tool.
The impression that most users will come away with after looking at the
material contained in any of the reference documents is that effectively
controlling access to a UNIX system could turn into a full-time task.
Unfortunately, even if you don't aim to master the intricacies of UNIX
security, a thorough understanding is highly recommended to allow you to
effectively use the available tools in keeping your system secure.
Note: References to security in this paper refer to standard current
releases of HP-UX, versions 7 through 9, as implemented on HP's
series 700 and 800 machines.
This paper does not apply to the special 'B1' security level UNIX
release: HP-UX BLS.
UNIX Security Concerns
----------------------
Security concerns can be divided into the following topics:
- User and Group related security concerns.
Including login security, weak passwords, etc.
- File system related security problems.
- Logfile analysis
- Network related security problems
I'll point out HP-specific concerns with each of these topics, starting
with brief introductions to each topic.
User and Group Related Security Concerns
----------------------------------------
Login security
--------------
UNIX systems control system access and associated privileges using user
accounts. A user account is defined by making entries in /etc/passwd,
each entry defines the following account attributes:
- login name
- encrypted password, and optional password aging data
- numerical user ID
- numerical group ID
- comment
- home directory
- default shell
The user ID number is the primary mechanism used to separate different
users from each other, and allows file ownership to be traced back to
the user that created the file.
Although different users may be defined with the same user ID number, it
will not be possible to distinguish between such users once they have
logged in. As this makes prevents effective auditing of security
violations, shared user IDs should not be allowed.
The system grants special (superuser) capabilities to any users defined
with a zero user ID number. UNIX contains no mechanism for granting
subsets of superuser capabilities (comparable with MPE's AM, PM, OP
capabilities), hence superuser capability is an all-or-nothing affair.
Superusers may essentially do or access anything on the system, this
is therefore the 'holy grail' of hackers everywhere.
The Group ID number is used to define a user's primary group membership.
Although this is primarily used as a mechanism to allow file access to
be shared between different users requiring access to the same files,
group ownership may also confer (on HP-UX) some additional capabilities.
UNIX systems traditionally define 'pseudo' account entries in the
/etc/passwd file, such as user entries for date, who, sync and tty.
HP-UX has moved towards eliminating logon access to these commands by
removing these entries from the password file, this has the benefit of
only allowing access to these commands to users who are in possession of
valid account IDs and passwords. Alternatively, such administrative
accounts should be setup with locked password fields to prevent their
being used for interactive logins.
User Groups
-----------
Anyone trying to figure out exactly how HP-UX implements group security
is in for a confusing time, here follows is what we managed to figure out.
Be warned, this material is not intended for those of a sensitive
disposition...
Traditionally where group membership is concerned, UNIX implementations
fall into two main camps having the following features in common:
- every group has a unique name and Group ID number
- all groups are defined in the /etc/group file, containing the following
fields for every group entry:
- group name
- optional encrypted group password
- group ID number
- list of users who are group members, separated by ','s
- every user belongs to a primary group, as defined in the /etc/passwd
file, but may also be assigned membership of other (secondary) groups
within the /etc/group file.
- primary group membership is used when creating new files. The user's
primary group ID is assigned to any files built, and becomes the file's
group.
- both primary and secondary group IDs are used when deciding what access
rights the user has to any particular file.
- Note that a user might only be assigned group membership by reason of
their /etc/passwd entry, this (primary) group membership does not have
to be explicitly defined in the /etc/group file, although it should be.
At this stage, the two UNIX camps diverge along the following lines:
- System V UNIX only allows a user to reside in a single group at any
given time. The newgrp(1) command may be used at any time to switch
the user's primary group ID to that of another group.
Users are able to switch into two classes of groups:
1) groups that they are defined as members of via the /etc/group file
2) groups that they are not members of, but only if the group has a
password defined in the /etc/group file, and the user can supply it.
- BSD derived UNIX systems allow a user to be a member of more than one
group at the same time. When a user logs in, they are assigned primary
group membership as defined in the /etc/passwd file, as well as
secondary membership of all groups in the /etc/group file where they are
defined as members.
The newgrp command serves very little (if any) purpose in BSD UNIX, and
is apparently omitted in many implementations.
- HP-UX conforms to the BSD-system, with the following peculiarities:
- each process has a list of up to 20 (typically) groups to which it
may belong at the same time.
- processes are allowed to access files if any of the groups that they
are a member of is allowed access (see section on ACL below).
- the newgrp(1) command may still be used at any time to switch the
users's primary group ID to that of another group. As the user is
already a member of all groups to which they are assigned membership,
the command serves only to allow them to become members of groups that
they are not members of, but only if the group password is defined and
the user supplies it.
- HP-UX introduces one further complication: it makes use of the file
/etc/logingroup. If this file exists, it defines the initial list of
groups that a user is to assigned membership of. In other words, it
defines a list of groups whose files a user should be allowed access
to without having to use the chgrp command.
File /etc/logingroup has an identical structure to that of /etc/group,
although the only significant fields are the following:
- group name
- list of users who are group members, separated by ','s
The structure is identical to /etc/group so that the two files may be
linked together for simplicity.
Any of the following scenarios may occur:
1) /etc/logingroup missing or empty.
Default group access list is empty, only group ID is the primary
group defined in /etc/passwd. Use newgrp command to gain access
to any secondary groups.
2) /etc/logingroup linked to /etc/group.
Default group access list is the entire list of available
secondary group IDs defined in /etc/group. The newgrp command is
only useful for gaining access to passworded groups that the user
is not defined as a member of.
3) /etc/logingroup contains a subset of the /etc/group data.
User is granted group membership to a subset of the available
groups. The newgrp command may be used to access secondary groups
not defined in /etc/logingroup.
File /etc/logingroup should not contain any group IDs which are not
also defined in /etc/group. If the group is defined within /etc/group
but not assigned to the user, then membership will be granted. If the
group is not defined at all within /etc/group, then membership is
still granted. As this behavior is not documented, do not rely on
it remaining unchanged in future releases.
- HP-UX documentation claims that /etc/logingroup is only available
on Series 800 machines (reference #10, page 5-7). This is incorrect,
it works fine on all series 700 and 800 machines.
- HP-UX documentation warns that no tools exists to ensure that entries
in files /etc/passwd, /etc/group and /etc/logingroup are compatible.
We recommend careful cross checking, and using the pwck command to
scan the default password file for inconsistencies, and the grpck
command to check the group file.
- HP-UX documentation (the man page for initgroups) contains the
following somewhat plaintive comment:
WARNINGS: On many systems, no one seems to keep /etc/logingroup
up to date.
- a group may have up to 200 users associated with it.
Group Passwords
---------------
HP-UX shares the following feature with all other UNIX implementations:
Groups may be assigned passwords if desired. All security references
consider this to be a bad idea for the following reasons:
- If group passwords are defined (the second field in file /etc/group),
then users who are not members of the group, but who know the group
password, will be able to use the newgrp(1) command to change their
group identification to this group. If no password is defined (or if
the password field is locked), then no user will be able to use the
system newgrp(1) command to change their identification to this group.
As group passwords are by nature shared, and as this approach to
security is very difficult to enforce, we strongly recommend that group
passwords are not used, and that any existing definitions be removed.
- note that even if a user is assigned secondary group membership of a
group, if they use newgrp to change their primary group ID to the group,
they'll still be asked the group password, if one is defined.
- world-read access must be available to /etc/group, and no equivalent
of /.secure/etc/passwd is available to shield the encrypted passwords
from curious hackers.
In addition to this list, HP-UX documentation contains the following
warning:
- no tool exists for setting group passwords in /etc/group, hence you'd
have to figure out the encrypted value of whatever password you're
using, and edit the file manually to add it. Some UNIX implementations
have a gpasswd command that allows group passwords to be manipulated
more easily, but not HP-UX.
If this isn't enough, the man page for newgrp warns that support for group
passwords may be omitted from future releases of HP-UX, further reason to
steer well away from their use.
Listing Group Ownership
-----------------------
If you want to report the group membership of a particular user, the id
command can be used to report on the default group membership after login
(regardless of if the user is currently logged in or not). The groups
command may also be used to determine exactly how group membership is
conferred on any user.
The following forms of the groups command are allowed:
- groups -p user
shows group ownership granted via /etc/passwd file
- groups -g user
shows group ownership granted via /etc/group file
- groups -l user
shows group ownership granted via /etc/logingroup file
- groups user
ORs together all of the above output.
Note that reversing the order of parameters, and specifying something of
the form 'groups user -p' will not generate any error, and will not work
as expected. In this case, the trailing parameter is simply ignored.
Login Security Weaknesses
-------------------------
A major weakness of UNIX security systems (as discussed in reference #5)
is the world-readable nature of the system password file /etc/passwd.
Brute-force password cracking programs are widely available that allow
cracking of many passwords typically in use. Allowing network-connected
users to upload copies of user's encrypted passwords allows them to
devote extensive resources to cracking the passwords on a remote system,
away from prying eyes.
The shadow password file /.secure/etc/passwd contains encrypted user
passwords, but is secured to prevent user read access.
The shadow password file contains the following fields on HP-UX:
- logon name
- encrypted password, and optional password aging data
- numerical Audit ID
- audit flag
Passwords defined in /.secure/etc/passwd take precedence over those in
/etc/passwd, even if the file doesn't exist!
The presence of directory /.secure is actually the indication that a
system has been converted to 'trusted' system status, even if the
directory is empty. There is a slightly unfortunate aspect to this
behavior: if you build the directory manually, but neglect to construct
a shadow password file within it, you will be locked out of the system.
Trusted System Status
---------------------
The HP-supplied System Administration Manager (SAM) is used to convert
an HP-UX system to 'trusted' status.
The following steps are performed by SAM during the conversion process:
- /etc/passwd file is copied to /etc/passwd.old.sav backup file
- passwords are copied from /etc/passwd to /.secure/etc/passwd. This
new file is created without world read access.
- encrypted passwords in the original file are replaced with '*'.
- Audit ID is created for each user
- the audit flag is set on for all users'
- at, batch and crontab files are converted to use Audit ID.
Notes: If you're converting to trusted system status, don't leave behind
the /etc/passwd.old.sav backup, it contains a copy of all
passwords at the time of conversion, although it is secured
against world read-access. It can come in very useful, however,
if you just intend testing trusted system features, and intend
'backing-out' later (see below).
Notes: Passwordless users in original /etc/passwd file are converted
into passwordless entries which are expired. This is NOT any
better secured that it was to start with, because such users are
still able to login, they'll just be forced to enter new
passwords when they do so.
Notes: HP documentation claims that all users are forced to use
passwords as part of the conversion process. This may be true on
some HP-UX versions only. We've seen cases where passwordless
user entries were misconverted by SAM, although this seems to
have been resolved on HP-UX 9.0.
A significant benefit associated with trusted systems is the
availability of enhanced system auditing functions. Many of these
are only available with trusted systems, as they make use of the
unique user Audit ID number assigned during the conversion process.
There are a few problems associated with use of SAM, as summarized
below:
- SAM doesn't provide a menu item for turning off trusted system
status.
- if you want to experiment, and hope to revert to non-trusted
status after your tests, don't. There is no easy way to turn off.
If you insist, the following list summarizes the necessary steps:
1) recover encrypted passwords from shadow password file, and re-
insert them in the default password file.
2) Turn off auditing:
/audsys -f
3) Remove the /.secure directory and its contents:
rm -r /.secure
Obviously, before performing these steps you should verify that the
/.secure directory doesn't contain any other significant files. Don't
remove this directory until you've verified that steps 1 and 2 have
been completed successfully.
Be very careful when performing these steps, it's very easy to lock
oneself out of the system if the correct encrypted passwords are not
correctly merged back into the /etc/passwd file (this is where the
backup file /etc/passwd.old.sav can come in useful).
HP-UX Group Privileges
----------------------
HP-UX allows special attributes to be associated with groups. It allows
some superuser-like capabilities to be controlled by defining which
groups they are accessible from. In this way it becomes possible to
distribute superuser accessible commands to other users without allowing
them full access to all other superuser capabilities.
This allows some (slight) relaxing of UNIX's 'all or nothing' approach
to distributing privileged capabilities. Privileged groups are an
HP-UX specific feature.
The following capabilities may be controlled:
- setting real-time priorities
- locking data in memory
- changing file ownerships (chown)
- lock file that are open for read access
- use setuid() and setgid() to change process real user/group IDs
In particular, this mechanism may be used to secure the chown command,
which has the potential to be misused. The chown command may be used to
change the owner ID of a file (or files) to another specified owner. By
default, on HP-UX, this command may be used by any user to assign
ownership of their own files to any other user, including root.
For example, HP-UX's disk-space accounting facility may be used to
report the total disk usage of all users. It's possible for users to
conceal their total disk usage by using the chown command to assign the
ownership of their own files to other users.
On BSD-derived UNIX implementations, chown usage is limited to super-
users only. By modifying the group privilege file /etc/privgroup via
the setprivgrp command, it's also possible to close this loophole on
HP-UX, by limiting usage of the chown command to users who are members
of specified groups only.
Although this doesn't appear to be covered by any HP documentation, it
appears that users are assigned the group privileges associated with
their primary group ID, and of all secondary groups defined within file
/etc/logingroup.
HP-UX documentation recommends that you not rely on the privileged group
mechanism to restrict access to the setuid and setgid system calls.
They do not guarantee that it will be supported by future releases of
HP-UX.
Ambiguous Account UID and GID fields
------------------------------------
Although not specific to HP-UX, shared user ID numbers within the
/etc/passwd file can cause problems in uniquely identifying users
responsible for security breaches.
By converting to trusted system status, the only area where the
ambiguity is resolved is in the area of audit records.
Ambiguous user/group ID numbers will create problems in the following
areas:
- resolving file ownership
- identifying the origin of system log records
Despite what is claimed by HP-UX documentation, CRON log files do NOT
seem to refer to Audit IDs, hence they are affected by ambiguous user/
group ID entries.
File System Related Security Problems
-------------------------------------
File System Security Implementation
-----------------------------------
UNIX implements file access security at three levels (or domains):
- owner access
- group ownership
- everyone else (world)
At each level, access permissions are defined which control file access
according to the type of operation, as follows:
- read permission
- write permission
- execute (file) or search (directory) permission
Each permission may be present or missing from each of the three levels,
each permission and level are quite independent of each other.
Permissions may be modified using the chmod command, and can be listed
using ls -l (or ls -ld for directories).
Program files may also have any of the following permissions associated
with them:
- set User ID capability
- set Group ID capability
- sticky-bit capability
File access permissions are defined by the value of the Modes field,
which is interpreted as follows (modes are displayed as an octal number,
combining all 16 possible bit values into up to 6 numeric digits):
..................... read | owner
: ................... write | access
sticky bit ................. : : ................. execute |
: : : :
set GID ............... : : : : .............. read | group
set UID ............. : : : : : : ............ write | access
: : : : : : : : .......... execute |
file | .......... : : : : : : : : :
type | ........ : : : : : : : : : : ....... read | other
| ...... : : : : : : : : : : : : ..... write | access
| ... : : : : : : : : : : : : : : ... execute |
: : : : : : : : : : : : : : : :
- ----- ----- ----- ----- -----
O O O O O O octal digits
When a file is built it is assigned the uid and gid of the creator.
The default mask settings are determined by the current umask value.
Umask may be set at the following levels:
- system wide
- user's environment file
- at command line
- programatically when file is created
Although HP-UX conforms to standard UNIX implementation, it's worth
noting the following:
- The three domains are not hierarchical, they are mutually exclusive.
In other words, the file owner is NOT considered as a member of the
file's group, and members of the file's group are not allowed file
access via the world permissions.
- The file owner is generally the file's creator, but may be assigned
to another user using the chown command.
- For directory files, write access allows the altering of privileges
associated with files within the directory. Read access allows the
directory contents (list of files in the directory) to be listed, and
execute (or search permission) access a program to use the directory
as a component of a file's pathname. The cd command requires search
permission (only) to be used on a given directory.
- HP-UX uses the SETUID attribute on directories to indicate that the
directory is hidden. This is part of the HP-UX context dependant
file structure.
Sticky-Bits and Directories
---------------------------
HP-UX provides an additional mechanism for protecting the contents of a
directory, taken from System V UNIX:
- if the directory 'sticky-bit' attribute is set, then files within the
directory may only be removed (using the rm command) by the owner of
the directory (or by users with write-access to the file).
If this is not set, then any user possessing write and search (execute)
access to the directory is able to remove a file regardless of whether
they possess any access to the file itself.
This is a useful feature, allowing a measure of protection to the
contents of directories containing 'temporary' files intended for read-
access by many users.
HP-UX Shared Library Security Implications
------------------------------------------
Shared library support, introduced with HP-UX 8.0, despite being
thoroughly familiar to anyone who's worked on an HP3000, has created a
few ripples in the HP-UX world. And, no, we're not even talking about
HP's inability to maintain forward compatibility between some shared
libraries created under HP-UX 8.0, and run-time HP-UX 9.0 systems. We
speak from some experience here, after having tried to maintain software
compatibility between HP-UX versions 7, 8 and 9.
While a description of shared library implementation or use is beyond
the scope of this paper, there are some security ramifications
associated with their introduction.
The directories /lib and /usr/lib contain many shared library files,
used internally by HP-UX command files.
If these directories are world-writable, then technically capable
intruders could subvert the functioning of many system commands.
Any tampering with the contents of these groups could easily be
catastrophic for the system.
HP-UX Access Control List (ACL) extension
-----------------------------------------
HP-UX implements an additional access control mechanism known as Access
Control Lists (ACL), this is analogous to the Access Control Definition
(ACD) mechanism implemented on MPE based HP3000s, and recently enhanced
by the HP3000's entry into the world of POSIX-compliance.
ACLs allow discretionary access control to be enforced, and allows
access permissions to be defined at a finer level than that allowed by
UNIX's traditional UNIX access modes. File access may be allowed or
refused on basis of user, group, or any combination. File access may be
allowed or restricted to individual users, regardless of what group or
groups the user is a member of.
On HP-UX the chacl command is used to change to access control list
of a file, and the lsacl command is used to display ACL permissions
associated with a file.
Each entry specifies the r/w/x access permissions associated with a
particular user ID/group ID combination. Up to 13 elements may be
specified in addition to the three 'base' elements always present.
User and Group may be specified in any of the following ways:
- name
- number
- '%' meaning any user or group
- '@' meaning the current file owner or group
When a file is created, the UNIX-style access permission word is mapped
into an equivalent three-element ACL list:
(uid.%,mode) .. file owner base ACL entry
(%.gid,mode) .. file group base ACL entry
(%.%, mode) .. 'other' user base ACL entry
The setacl command is used to add new ACL elements,
(joe.tech, rwx) -- allows r,w,x access to specified user
(frank.%, ---) -- refuse all access to user frank in no specific
group.
The following search order is used to determine if file access is
available:
- (user.group, rwx) specified user and group
- (user.%, rwx) specified user, any group
- (%.group, rwx) any user, specified group
- (%.%, rwx) any user, any group
The entire list is always checked, and the entry that matches the
request (the most specific matching entry) is used. More specific
entries anywhere in the ACL list take precedence over less specific ones
that also match.
If a process has a supplementary group IDs, the access mode of all
matching entries that match at the same level are ORed together.
By mapping the traditional UNIX access modes into the 'base' ACL
entries, backward compatibility is provided.
If more that one access is requested, then access is only provided if
all requested accesses are allowed.
Problems associated with ACL
----------------------------
One of the more significant problems is the inability of the HP-UX PDF
facility (see below) to correctly track file ACL descriptions.
UNIX chmod command will lose ACL entries if an explicit effort is not
made to preserve them (-A option). This is because (to conform with
POSIX .1 standard) optional entries are deleted.
If UNIX chown command is used to change a file's user and/or group IDs,
then any specific matching ACL entries will be remapped to the new
values. However, if the original file already contained an explicit ACL
entry for the new user/group ID, then the ACL list is not changed, and a
change in access permissions may result.
ACLs should be used for user files & directories, not for files that are
manipulated by system utilities. These utilities may remove optional
ACL entries without warning.
Backup utilities should be checked: only fbackup and frecover can handle
ACL correctly. cpio and tar will lose optional ACL information.
ACL specifications cannot be used in cases where user/group names
contain .+%@ or * characters, so don't.
ACL specifications cannot be transferred over a network.
HP-UX 'Filesets'
----------------
HP-UX uses a concept known as a 'fileset' when referring to logical
groups of files that supply software functionality. This term isn't
used in the standard UNIX reference sources.
A fileset description consists of two items: a directory located within
the /system directory, and a file within the /etc/filesets directory.
This file contains a list of all files considered part of the fileset.
Individual files are never listed as being members of more than one
fileset (at least, we've never seen this happen).
HP-UX filesets are referred to in HP-UX Installation and Update
procedures, where you may decide whether individual filesets should be
installed or not, and also by the HP-UX rmfn (remove functionality)
command, which allows unwanted features to be deleted from a system.
In neither case are you able to remove a fileset that would be required
for other (required) functionality to work.
A fairly complete list of HP-UX filesets is found in Reference #8,
Appendix A.
HP-UX Product Description File (PDF) facility
---------------------------------------------
HP-UX contains a powerful facility that allows you to check whether
files have been modified or not. The facility may be used independently
of the trusted system status.
It offers a superset of the checking available on other UNIX
implementations via the sum, cksum and upkeep commands. Incidentally,
although both checksum commands are available on HP-UX, there is no
manual help available for the cksum command.
HP-UX is delivered with a number of PDF input files, each containing
information describing the file that are part of a particular fileset.
Considering that the PDF facility gives you the ability to monitor
changes in operating system files, it's quite surprising that the
facility is so poorly documented in HP-UX documentation. We've found
references to it limited to man entries for pdf(4), mpdfck(1M),
pdfdiff(1M) and mkpdf(1M) only.
HP-UX fileset directories are located in the /system directory, the PDF
input file for each fileset is stored as the file pdf, within each
fileset directory.
HP documentation recommends that you rebuild all PDF input filesets
following (or as a part of) conversion to trusted system status. We
found this to be unnecessary, as a normal installation of new HP-UX
version results in the installation of (theoretically) good PDF input
specification files supplied by HP.
PDF input files normally contain the name of the fileset at the start of
the file, followed by one line for every file supplied with the fileset,
with trailing lines specifying the total size of all files in the
fileset.
The following detail information is included on each file detail line in
the PDF input file:
pathname .. absolute pathname ('?' indicates file is optional)
owner .. owner name or UID number
group .. group name or GID number
mode .. file type and permissions (ls -l format)
size .. size in bytes
links .. total hard links
version .. numeric revision number
checksum .. CRC checksum
linked to .. hard/symbolic linked files
Any field may be blank, in which case the value is not checked.
The following notes focus on particular PDF features:
- checking PDF status
The pdfck command is used to check the current status of files within
a PDF fileset against the PDF input file specification. Unfortunately
the output of pdfck is very difficult to read.
- CRC checksum.
PDF uses the IEEE 802.3 Cyclic Redundancy Check (CRC) algorithm to
derive a checksum value for each file, and is able to detect if this
value has changed. No information can be inferred, however, on the
magnitude of changes that caused any checksum mismatch.
- Standard compliance.
The PDF is based on a draft proposal submitted to the IEEE POSIX .2
committee. The proposal was subsequently dropped from the standard.
I'm not sure if any conclusions should be drawn from this.
- File Access Mode changes.
File access mode changes detect changes made to a file's access
permissions, file type, Set UID and Set GID bits, and to the sticky-
bit status of the file.
- File Size Changes.
The PDF input file stores the size of a file in bytes, or (for device
special files) the major/minor device number. Directory sizes changes
are not detected.
- HP-UX version 7 Limitations.
The PDF facility was (apparently) not available on all HP-UX version 7
systems. In addition, the checksum algorithm used by HP-UX release 7
is different from that used by releases 8 and 9 (which are, however,
mutually compatible).
The following limitations, some of which are major, apply to the PDF
facility:
- Validity of input files.
The validity of information as reported here is dependant on the PDF
input file being correctly initialized. If the input file does not
correctly describe the files within a fileset, than this report will
generate potentially large numbers of misleading error messages.
- Detection of new files.
PDF can't detect if new files have been added anywhere. As a result
it is of no help in detecting Trojan horses.
- Covering dynamic files.
PDF input descriptions generally do not cover system configuration
files that the user is expected to setup, and files (such as system
auditing log files) that change constantly. Some other means should
be used to verify that these files remain correctly secured.
- Checksum algorithm weaknesses. The CRC checksum algorithm may be
spoofed fairly easily, that is, if a file has been modified, then the
resulting checksum change may be 'canceled out' by changing another
(unimportant) area of the file, and retrying different values until no
checksum mismatch is detected. To be considered reliable, a
cryptographically sound checksum algorithm should be substituted.
- Tracking ACL description changes.
The PDF facility does not track or detect changes made to a file
access permissions, if defined using Access Control List (ACL) syntax.
Many ACL changes will in fact be detected, as many will change the
equivalent access permission value, but this cannot be guaranteed.
Bearing in mind that both PDF and ACL represent HP-written extensions
to UNIX, it's somewhat unfortunate that PDF doesn't track ACL changes.
As the following example shows, this is a significant loophole.
Consider the security on the ps command file. The following PDF
description is contained within the UX-CORE fileset:
/bin/ps:bin:sys:-r-xr-sr-x:24576:1:70.2:1853093805
checking this (via pdfck) reveals no problem.
If the security on this file is modified to allow non-superuser access
to the file:
chacl "fred.users+rwx" /bin/ps
as verified using the lsacl command:
lsacl /bin/ps
(fred.users,rwx)(bin.%,r-x)(%.sys,r-x)(%.%,r-x) /bin/ps
then re-running the pdfchk on the UX-CORE fileset doesn't detect any
problem at all with the file, despite that fact that a critical UNIX
command file is now vulnerable to tampering by user fred.
These problems aside, pdfchk remains a useful means of verifying that no
significant files have been tampered with.
On our system, following a correct installation of HP-UX 9.0 (and
without going into details on the disc reorganizations required to
effect that installation), out of the approximately 13274 input PDF file
description entries, the following summarizes the total number of each
type of PDF mismatch detected:
deleted : 388
owner : 1
group : 13
links : 5
checksum : 7
mode : 3
size : 7
version : 0
System Logfiles
---------------
List of Available Logfiles
--------------------------
The following list is a (fairly complete) list of the system logfiles
that are potentially available on an HP-UX system. Compiling such a
list was, as you might imagine, a non-trivial task...
logfile type contains...
------------------------ ---- ---------------------------------------
/.secure/etc/auditlog_1 primary auditing logfile
/.secure/etc/auditlog_2 secondary auditing logfile
/etc/btmp bin bad login attempts.
/etc/wtmp bin good logins, time changes, reboots.
/etc/ptydaemonlog asc pseudo-terminal open/closing info (?)
/tmp/clusterlog asc HP-UX cluster environment event logging
/tmp/updatelog asc logs update and install commands, tracks
update, install and removal of filesets.
/usr/adm/pacct* bin accounting info (SVR4) (?)
/usr/adm/sulog su command logging
/usr/adm/OLDsulog old su logfile, renamed on system reboot
/usr/adm/syslog asc miscellaneous system log file. User
accessible logfile.
/usr/srm/OLDsulog asc old syslog, renamed on system reboot
/usr/adm/shutdownlog asc shutdown and rebooting log
/usr/lib/cron/log asc logs use of cron, at commands
/usr/lib/spell/spellhist asc use of spell command (!)
/usr/spool/mqueue/syslog asc (?)
Auditing on a Trusted System
----------------------------
The HP-UX specific auditing subsystem solves one important limitation
of traditional logging: the inability to resolve ambiguities between
accounts having matching User/Group ID numbers. As conversion to a
trusted system assigns unique Audit ID numbers to every account, the
auditing subsystem can always report the precise user responsible for
any event.
While the details are beyond the scope of this paper, SAM allows the
configuring of the following categories of system activity:
Users:
Individual users may be audited
Events:
The following types of events may be logged:
object creation, deletion, access permission modification
object opening and closing
process operations
removable media mounting/unmounting
user logins and logouts
administrative and privileged operations
interprocess communication
user-defined events
User-login logging is handled differently from other event classes:
selected event classes are only logged for users who have themselves
been selected for auditing, however when the user-login event class is
selected, all user logins are logged regardless of whether the
individual user is selected or not.
System Calls:
the individual system calls associated with the event list may be
audited, as well as many significant programmatic calls, for example
setuid and setgid.
In general, you may log successful and/or unsuccessful attempts to
access any of the above events.
Network Related Security Problems
---------------------------------
Network Security Overview
-------------------------
The Network Information Service (NIS) is an optional network service
that allows a single system (the NIS master server) to administer
password, group and other files over the network. Networked systems
(the NIS clients) access the database files stored on the master server
as if they were stored locally.
The most significant aspect is that account and configuration data need
only be maintained on a single machine in the network.
Building NIS Databases
----------------------
ypmake is a shell script (located in /usr/etc/yp) that is used on the
NIS server to build (or rebuild) the NIS databases. Once ypmake has
completed, yppush is used to notify NIS clients of the change, and to
make them upload to updated maps to their machines.
The standard NIS databases are created from the following ASCII files:
/etc/passwd
/etc/group
/etc/hosts
/etc/protocols
/etc/netgroup
/etc/rpc
/etc/networks
/etc/services
NIS Authentication Weaknesses
-----------------------------
NIS possesses one weakness: the authentication mechanism used by HP's
implementation is not completely secure. Network clients that need
password authentication to be performed by the master server present to
the server a UID GID pair, and up to 8 secondary GIDs; the server uses
these to determine if the request is authorized. Unfortunately, the
server has to trust that the client is providing the correct UID and GID
data. In essence, the client can claim to be any user, and the server
has no way to verify this information.
An important exception to this loophole presented by the superuser on
the client machine. Any authentication request that originates from a
superuser (UID 0) is changed to UID -2, which is defined to be 'nobody'.
As a result of this, the superuser on an NIS client has no special
access rights on the NIS server.
A user-written program running on an NIS client may set their UID/GID
numbers to any required value, and may therefore access any file on the
NIS server, as long as the file is not owned by root.
In general, the NIS server may be protected against this kind of hostile
attack by a number of mechanism, including limiting the filesystems that
are exported, by exporting them read-only, by limiting the machines to
which they are exported, or by setting the owner of sensitive files to
root.
Network Password Files
----------------------
An NIS client site's system password file /etc/passwd (or the secure
/.secure/etc/passwd) can contain entries that begin with a '+' or '-' in
the first column.
Such entries cause the NIS master server to be queried, and any matching
entries that it returns will be included or excluded on the NIS client
site, as if they had been maintained locally.
Such entries cause the inclusion (or exclusion) of entries located in
the NIS server's Network Information System (NIS) network database file.
Although a full description of the NIS database is beyond the scope of
this paper, the following points should be noted by users who have
converted to trusted system status, and who therefore are using a
secured shadow password file:
In this case, encrypted passwords previously held in the /etc/passwd
file are now stored in /.secure/etc/passwd. In this case, the NIS
database will not contain encrypted passwords, as it extracts encrypted
passwords from the standard /etc/passwd file. As the NIS database is
itself readable by anyone with access to NIS commands such as ypcat,
this is necessary to prevent security from being compromised.
According to HP documentation (reference #9), the following steps must
be performed if you wish to use the NIS database to maintain other data
held in the password file, while still keeping encrypted password data
secure:
1) Build the NIS password database on the master server using a
/etc/passwd file that doesn't contain encrypted passwords.
2) On NIS client sites using HP-UX, keep a copy of /.secure/etc/passwd
containing (correctly secured) encrypted passwords.
3) On non-HP-UX NIS clients, use the NIS escape syntax to keep
encrypted passwords in the NIS client system's /etc/passwd file.
In this case, the NIS server will authenticate the supplied
username, but the encrypted password held locally will be used
for password checking.
Remote System Administration
----------------------------
HP-UX release 9.0 contains some significant enhancements related to the
remote management of network security. In particular, SAM now contains
a Remote System Administration area that allows system management to
remotely administer networked systems.
Although this feature has only recently been released, preliminary
investigation has revealed the following:
When remote system administration is requested, SAM logs in to the
remote system, and creates a new account on the remote system (you
must provide the root password to the remote system to do this).
The new account is created with user name sam_exec, UID=0 and GID=1,
and is created with a copy of the root password currently used on the
remote system. This new account is used by SAM whenever logging in to
the remote system.
While not in itself a problem, this seems to be very lightly (if at
all) documented at present.
HP-UX DSCOPY logging limitations
--------------------------------
DSCOPY displays no evident security problems, with the exception of the
following: no logging of either successful or unsuccessful DSCOPY login
attempts from remote systems is performed. At present, this seems to be
an unnecessary loophole, allowing brute-force security attacks to be
performed without leaving any trace of the number, time or origin of the
attack.
The B1 certified HP-UX BLS version does contain facilities for logging
these attempts, but no such facility exists in standard HP-UX.
Security Auditing Techniques
----------------------------
VESOFT's SecurityAudit/UX
-------------------------
VESOFT have recently released a security auditing tool for HP-UX based
systems. While this is not the forum to promote the product, we make
use of a number of techniques that may be of interest.
Managing PDF output
-------------------
VESOFT's SecurityAudit/UX product makes use of the supplied PDF files to
verify file system consistency, but performs a number of additional
checks to close the loopholes noted here. In particular, we track
changes to file ACL descriptions, and flag new files not covered by any
PDF description file. We also can report on files that we consider to
have weak security, regardless of whether they are covered by a PDF
description file. Another very useful feature is the ability to
summarize the somewhat verbose output of the pdfck command, by
generating output reports that contain the number of each type of
violation detected within each PDF fileset.
It's also very important to realize that any sufficiently capable
intruder is able to modify or even add a new PDF description of a file
that has been altered or added. It's vital to track changes to the PDF
input files themselves, and to maintain backup copies in secure
locations. We intend to maintain encrypted versions of these files to
prevent even superuser intruders from tampering with the file
descriptions.
Tracking File System Changes
----------------------------
VESOFT's SecurityAudit/UX product tracks changes to file system status,
specifically to allow changes in file ACL specifications to be detected,
and to track when files are created and deleted.
We encountered problems when trying to determine the date on which a
file was created, due to a number of 'features' of HP-UX. In particular
every file has the following date/time fields associated with it:
- atime access status : last access time of file data
- mtime mod status : last modification of file data
- ctime change status : last change time of i-node status
These time fields are changed by the following actions (among others):
- atime read operations
- mtime write operations
- ctime file access permissions, userid, links change operations
However, there is no i-node last access time, hence access and stat
functions don't modify any of the three time fields.
The time fields are maintained for directories just as for any other
file type, with the difference that directory data is modified when a
file within it is added or deleted.
The shell ls command can be used to display these fields. Possible uses
for the fields are to delete files that haven't been accessed since a
certain date, or to archive files that have been modified since a
certain time.
The touch command may be used to update any of these time fields to
either the current time, or to any specified time, depending on the
user's capabilities. In particular, a file creator may set a file's
access and modification times to any value. The i-node change time
can't be set to an arbitrary value, but it will be updated to the
current time.
On HP-UX, the fbackup utility may be used to perform an incremental
backup, in which files are only backed up if they have been modified
since a previous backup of the specified fileset. The fbackup utility
performs this by maintaining a database (/usr/adm/fbackupfiles/dates by
default) which records this information. However, fbackup will modify
all file inode change times to the current time the file is backed up.
This has an unfortunate effect on security auditing: it is impossible to
tell how old a file is by looking at any of the change time fields.
There is no equivalent of the HP3000 file creation time field, which
greatly complicates the life of a security auditing tool which attempts
to identify all newly created files on a system.
From a security auditing viewpoint we are most concerned about use of
the command to modify a file's modify or change date backwards, with the
intention of concealing a modification of the file's contents or access
permissions or ownership.
VESOFT's SecurityAudit/UX product is able to determine if a file is
newly created or not by maintaining an internal history database. We
record the first time that we see a file, and the file's i-node number.
On subsequent runs of the program we check the file's change dates and
i-node, and we can infer from this information if a file has been
modified since the last run. Currently we make use of this information
to derive two information fields: firstly the (approximate) age of a
file, and secondly a flag that indicates if any security problem
associated with the file has been newly detected, or has existed for the
entire life of the file.
This information is significant because it enables us to identify newly
created security problems: obviously a number of improperly secured
files may exist on your system, and we aren't always able to determine
whether or not the security problem can be solved without breaking a
program that requires the file's security to be the way it is. On the
other hand, a change in file security of a file that used to be
'correctly' secured is an indication of a significant security problem,
and we'll flag it as such.
Resolving Ambiguous User/Group IDs
----------------------------------
One facet of analyzing system accounting records that is somewhat poorly
handled by HP-UX commands is the area of resolving ambiguous user IDs
stored in accounting log records. We try to not only flag shared user
IDs as a potential problem, but in many cases we are able to resolve the
ambiguity by checking through the list of users who share a given user
ID, while ignoring users who are not also members of the logged group
ID.
We use the same technique when trying to determine the unambiguous owner
of a file. The ls command (for example) shows file user and group names
by scanning through /etc/passwd and /etc/group looking for the first
matching entry in each file, respectively. We can be slightly more
intelligent by looking for the first matching user who potentially has
access to the file's group. It's not guaranteed to resolve the
ambiguity, but it increases the chances.
Thanks...
---------
I'd like to express my thanks to the following:
- Serge Bojoulitch, principle developer of VESOFT's SecurityAudit/UX
product, for his work investigating HP-UX security issues, and for the
many suggestions and ideas he contributed to this paper.
- Eugene, Vladimir and Anne Volokh, for their help and encouragement
during the development of SecurityAudit/UX.
- Our numerous beta test sites, for their feedback and criticism during
product development, and even for the occasional bug report...
References
----------
The following sources provide information on general UNIX security topics:
1) UNIX System Security. Rik Farrow.
Addison-Wesley, 1991. ISBN 0-201-57030-0.
2) UNIX System Security. David A. Curry.
Addison-Wesley, 1992. ISBN 0-201-56327-4.
3) Practical UNIX Security. Simson Garfinkel and Gene Spafford.
O'Reilly & Associates, 1991. ISBN 0-937175-72-2.
4) UNIX Security. N. Derek Arnold.
McGraw-Hill, 1993. ISBN 0-07-002560-6.
5) The Cuckoo's Egg. Clifford Stoll.
Doubleday, 1989. ISBN 0-385-24946-2.
The following sources provide information on HP-UX specific security
topics:
6) VESOFT SecurityAudit/UX User Manual (version 1.6).
VESOFT, Inc, 1993.
7) HP-UX System Security Manual (2nd edition).
Hewlett Packard, 1992. Manual Part Number B2355-90045.
8) Installing and Updating HP-UX 9.0.
Hewlett Packard, 1992. Manual Part Number B2355-90039.
9) Installing and Administrating NFS Services (2nd edition).
Hewlett Packard, 1992. Manual Part Number B1013-90009.
10) How HP-UX Works: Concepts for the System Administrator (4th edition).
Hewlett Packard, 1992. Manual Part Number B2355-90029.
The Author
----------
Paul Taffel has worked with HP3000 systems for the past 10 years, and has
held product management and development positions at Bradmark Computer
Systems in Houston (working with DB-General), and at APPIC in Paris
(developing StarJet/3000).
Paul currently works as a software developer with VESOFT in Los Angeles,
where he divides his time between enhancing VESOFT's HP3000-based products,
and managing development of VESOFT's HP9000-based SecurityAudit/UX product.