Hacker Chronicles 1/HACKER1.ISO/hack/unixhak2.txt

Text File | 1992-08-30 | 12KB | 383 lines

              On the Security of UNIX

              =-=-=-=-=-=-=-=-=-=-=-=

Recently there has been much interest in the security aspects of operating

systems and software.At issue is the ability to prevent undesired disclosure of

information, destruction of information,and harm to the functioning of the

system.This paper discusses the degree of security which can be provided under

the system and offers a number of hints on how to improve security.The first

fact to face is that UNIX was not developed with security,in any realistic

sense,in mind;this fact alone guarantees a vast number of holes.(Actually the

same statement can be made with respect to most systems.)



The area of security in which is theoretically weakest is in protecting against

crashing or at least crippling the operation of the system.The problem here is

not mainly in uncritical acceptance of bad parameters to system calls (there

may be bugs in this area, but none are known)but rather in lack of checks for

excessive consumption of resources.



Most notably, there is no limit on the amount of disk storage used, either in

total space allocated or in the number of files or directories.Here is a

particularly ghastly shell sequence guaranteed to stop the system:





while : ; do

    mkdir x

    cd x

done



Either a panic will occur because all the i-nodes on the device are used up,

or all the disk blocks will be consumed, thus preventing anyone from writing

files on the device.In this version of the system,users are prevented from

creating more than a set number of processes simultaneously,so unless users

are in collusion it is unlikely that any one can stop the system altogether.



However, creation of 20 or so CPU or disk-bound jobs leaves few resources

available for others.Also, if many large jobs are run simultaneously,swap space

may run out, causing a panic.  It should be evident that excessive consumption

of diskspace, files, swap space and processes can easily occur accidentally in

malfunctioning programs as well as at command level.In fact UNIX is essentially

defenseless against this kind of abuse,nor is there any easy fix.The best that

can be said is that it is generally fairly easy to detect what has happened

when disaster strikes ,to identify the user responsible, and take appropriate

action.In practice,we have found that difficulties in this area are rather

rare,but we have not been faced with malicious users,and enjoy a fairly

generous supply of resources which have served to cushion us against accidental

overconsumption.



The picture is considerably brighter in the area of protection of information

from unauthorized perusal and destruction.Here the degree of security seems

(almost) adequate theoretically, and the problems lie more in the necessity for

care in the actual use of the system.Each UNIX file has associated with it

eleven bits of protection information together with a user identification

number and a user-group identification number (UID and GID).



Nine of the protection bits are used to specify independently permission to

read, to write, and to execute the file to the user himself, to members of the

user's group, and to all other users.Each process generated by or for a user

has associated with it an effective UID and a real UID, and an effective and

real GID.When an attempt is made to access the file for reading, writing, or

executing UID for the process is changed to the UID associated with the file;

the change persists until the process terminates or until the UID changed again

by another execution of a set-UID file.Similarly the effective group ID of a

process is changed to the GID associated with a file when that file is executed

and has the set-GID bit set.The real UID and GID of a process do not change

when any file is executed,but only as the result of a privileged system

call.The basic notion of the set-UID and set-GID bits is that one may write a

program which is executableby others and which maintains files accessible to

others only by that program.



The classical example is the game-playing program which maintains records of

the scores of its players.The program itself has to read and write the score

file,but no one but the game's sponsor can be allowed unrestricted access to

the file lest they manipulate the game to their own advantage.



The solution is to turn on the set-UID bit of the game program.  When, and only

when,it is invoked by players of the game,it may update the score file but

ordinary programs executed by others cannot access the score.  There are a

number of special cases involved in determining access permissions.  Since

executing a directory as a program is a meaningless operation,the

execute-permission bit, for directories, is taken instead to mean permission to

search the directory for a given file during the scanning of a path name; thus

if a directory has execute permission but no read permission for a given user,

he may access files with known names in the directory,but may not read (list)

the entire contents of the directory.



Write permission on a directory is interpreted to mean that the user may create

and delete files in that directory;it is impossible for any user to write

directly into any directory..Another, and from the point of view of security,

much more serious special case is that there is a ``super user'' who is able to

read any file and write any non-directory.The super-user is also able to change

the protection mode and the owner UID and GID of any file and to invoke

privileged system calls.It must be recognized that the mere notion of a

super-user is a theoretical, and usually practical, blemish on any protection

scheme.



The first necessity for a secure system is of course arranging that all files

and directories have the proper protection modes.Traditionally, UNIX software

has been exceedingly permissive in this regard;essentially all commands create

files readable and writable by everyone.In the current version,this policy may

be easily adjusted to suit the needs ofthe installation or the individual user.



Associated with each process and its descendants is a mask, which is in effect

anded with the mode of every file and directory created by that process.  In

this way, users can arrange that, by default,all their files are no more

accessible than they wish.The standard mask, set by login,allows all permiss-

ions to the user himself and to his group,but disallows writing by others.



To maintain both data privacy and data integrity,it is necessary, and largely

sufficient,to make one's files inaccessible to others.  The lack of sufficiency

could follow from the existence of set-UID programs created by the user and the

possibility of total breach of system security in one of the ways discussed

below(or one of the ways not discussed below).



For greater protection,an encryption scheme is available.Since the editor is

able to create encrypted documents, and the crypt command can be used to pipe

such documents into the other text-processing programs,the length of time

during which clear text versions need be available is strictly limited.The

encryption scheme used is not one of the strongest known, but it is judged

adequate, in the sense that cryptanalysisis likely to require considerably more

effort than more direct methods of reading the encrypted files.For example, a

user who stores data that he regards as truly secret should be aware that he is

implicitly trusting the system administrator not to install a version of the

crypt command that stores every typed password in a file.  Needless to say, the

system administrators must be at least as careful as their most demanding user

to place the correct protection mode on the files under their control.



In particular,it is necessary that special files be protected from writing, and

probably reading, by ordinary users when they store sensitive files belonging

to otherusers.It is easy to write programs that examine and change files by

accessing the device on which the files live.



On the issue of password security,UNIX is probably better than most systems.

Passwords are stored in an encrypted form which, in the absence of serious

attention from specialists in the field,appears reasonably secure, provided its

limitations are understood.In the current version, it is based on a slightl y

defective version of the Federal DES;it is purposely defective so that

easily-available hardware is useless for attempts at exhaustive

key-search.Since both the encryption algorithm and the encrypted passwords are

available,exhaustive enumeration of potential passwords is still feasible up to

a point.We have observed that users choose passwords that are easy to

guess:they are short, or from a limited alphabet, or in a dictionary.

Passwords should be at least six characters long and randomly chosen from an

alphabet which includes digits and special characters.



Of course there also exist feasible non-cryptanalytic ways of finding out

passwords.For example:    write a program which types out ``login:''on the

typewriter and copies whatever is typed to a file of your own.    Then invoke the

command and go away until the victim arrives..The set-UID (set-GID)notion must

be used carefully if any security is to be maintained.    The first thing to keep

in mind is that a writable set-UID file can have another program copied onto

it.



For example, if the super-user command is writable,anyone can copy the shell

onto it and get a password-free version of Shell Unix.A more subtle problem can

come from set-UID programs which are not sufficiently careful of what is fed

into them.To take an obsolete example,the previous version of the mail command

was set-UID and owned by the super-user.This version sent mail to the r

ecipient's own directory.The notion was that one should be able to send mail to

anyone even if they want to protecttheir directories from writing.  The trouble

was that mailwas rather dumb:anyone could mail someone else's priva te file to

himself.Much more seriousis the following scenario:  make a file with a line

like one in the password filewhich allows one to log in as the super-user.Then

make a link named ``.mail'' to the password file in some writable directory on

the same device as the password file (say /tmp).  Finally mail the bogus login

line to /tmp/.mail;You can then login as the superuser,clean up the

incriminating evidence,and have your will.



The fact that users can mount their own disks and tapes as file systems can be

another way of gaining super-user status.Once a disk pack is mounted, the

system believes what is on it.Thus one can take a blank disk pack,put on it

anything desired,and mount it.There are obvious and unfortunate consequences.

For example:a mounted disk with garbage on it will crash the system;one of the

files on the mounted disk can easily be a password-free version of Shell Unix;

other files can be unprotected entries for special files.  The only easy fix

for this problem is to forbid the use of mount to unpriv- ileged users.A

partial solution, not so restrictive,would be to have the mount command examine

the special file for bad data,set-UID programs owned by others ,and accessible

special files,and balk at unprivileged invokers.



Removed from Berkely Unix System by the Terminal Technician with glee....

--------------------------------------------------------------------------

   This file passed through the DEAD ZONE.  It is a phun place, and you

really should call it @ [phone].  300/1200/2400, 24 hours, 7 days.



A RING-BACK system:

          Call Once, let ring 1-2 times, HANG UP.

          Call back 20-45 seconds later and the system will answer.



    There is no way to connect on the first call, so don't let it ring a

    bunch of times or you'll get an answering machine.

Downloaded From P-80 Systems 304-744-2253