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.
Go to Adager's index of technical papers