Security versus Protection
What is the distinction between these two terms?
Protection: set of mechanisms that allow specification of who may do what with various objects.
Security: measures taken to ensure that protection mechanisms are not compromised.
A basic tradeoff: security versus ease of use for legitimate users
Kinds of security threats
Snoopers (curiosity)
Spies (corporate/governmental)
Pranksters (harmless to malicious). Two classes of "pranks" deserve particular attention:
Viruses
Worms
Thieves
Two basic concerns
Keeping unauthorized persons out
Confining authorized persons to authorized information/actions
For most outside penetrators, penetration is a two step process; getting on the system at all, and then using facilities available to them to get the access they ultimately want.
We will look at some of the ways people attack computer system security.
A disclaimer...
Note: Some would question the legitimacy of some of the things you read about - e.g. publishing the source code for viruses. One must resist the temptation to try some of these things out, of course; but by looking at the source code you read it should be easy to see that it doesn't take too clever of a person to come up with it, so publishing it doesn't really threaten security.
The best protection: physical security
e.g. DOD standards for systems holding classified data: no connections outside the physically secure facility. (But this can hinder usefulness)
Passwords
Question: The prime safeguard on most systems is the password system. How do unauthorized users crack this to get on a system in the first place?
Be sure to note problem with Unix /etc/passwd being world readable - a key loophole exploited by the Internet worm.
A world readable /etc/passwd would not be a problem if all users always chose good passwords...
but given that some don't, it's not a great idea if a system needs to be secure.
There is little than an operating system designer, per se, can do to improve password security. (And sometimes their efforts to do so have unintended effects as Grampp and Morris pointed out.) System management bears the brunt of the responsibility for educating users about the importance of good password practices.
This is a major task of the O.S.
We assume an adequate protection system that allows information and other resources to be protected in a fine-grained enough way. (Cf the previous lecture.) We now consider how to ensure that the integrity of the protection system can be maintained in the face of individuals who try to get around it.
Loopholes
What are some loopholes that people exploit (once already on the system) to gain additional unauthorized access?
Password cracking
This is easier once a miscreant is on the system
VMS SHOW USERS gives a list of people currently on. (An outsider must know both a username and a password; an insider need only guess a password given a username.)
On Unix, /etc/passwd is now accessible, giving a list of all users on the system, and possibly their encrypted passwords.
Some system log files contain usage patterns and the identity of certain authorized users that a hacker may want to target.
Ability to create and leave running a trojan horse login program.
Parameter checking
Loopholes in parameter checking by system services and trusted utilities.
Example: One mode of penetration used by the Internet Worm - a defect in Unix gets() (get string) library routine. The state of the run-time stack when gets() is called can be diagrammed as
________________________________ | | <---- | Space set aside to hold the | | | result string | | | | | |------------------------------| | | Argument list of gets() call |------ |------------------------------| | VAX call frame - including | | return address to caller |---> To caller's code |______________________________|
If the string the user types is too long, it will overwrite the argument list and then the call frame.
What the Internet worm did is take advantage of the fact that a network process (fingerd) uses gets(). By sending a carefully contrived string to it, it constructed the following structure on the stack:
________________________________ | | <---- | Worm code sent as a series | | | of individual bytes, filling | | | string space and argument | | | list space, and overflowing | | | into VAX call frame | | |------------------------------| | | VAX call frame - modified to | | | return to worm code above |------ |______________________________|
Example: network mail utility (sendmail) on Unix had a debugging option which forks a shell so that a remote maintainer can check around for correct delivery of mail. Should be turned off in production use versions, but was not on many Internet sites. Since sendmail runs setuid to root, the resultant shell ran as root!
Trojan Horses
These are programs that perform some function other than the intended one.
Things a trojan horse might do
Change protection of the files of the user running the program (and perhaps send mail notifying of this fact to creator of program.)
Create set uid shell in the directory of the creator of the program, but with uid of the person running the program.
A myriad of things are possible if the person running the trojan horse has privilege.
etc.
How do people get others to run their trojan horses?
Install as games or utilities that others want to run.
Install under name of a commonly used utility and take advantage of search path order in Unix.
Leave as a file called a.out for the an unsuspecting user. Since the name a.out is not in any descriptive of the program, a user (even a privileged user) might execute it to see what it does.
etc.
To protect yourself:
Never execute an unknown file - especially as root. (Note: measure of protection provided by Unix ability for root to su to another user.)
Be sure standard directories precede private directories on search path.
On Unix systems, a root shell should never have "." (the current directory) in it's PATH.
The Trojan horse discussed by Ken Thompson ("Reflections on Trusting Trust") is particularly insidious, since even source code is no defense against it.
Worms
Worm programs try to migrate from system to system by automating what an ordinary hacker otherwise does by hand.
The Internet Worm, for example, ran as a process on one system trying to penetrate other systems it was connected to using standard password cracking techniques and other security loopholes. It became a massive problem because oftentimes the same machine would be penetrated many times, resulting in multiple copies of the worm running on it trying to crack others. Eventually this cascaded to the point where systems were fully loaded just servicing the various instances of the worm on them.
The best protection against worms is the same as the protection against hackers whose techniques they automate.
Viruses
Virus programs are more passive. They are installed into an executable program so that the virus runs in addition to the regular code of the program. (Thus, they only become active when the program they have infected is executed.)
Examples:
Unix executable file
---------------------------------
| Header block - includes |
| total size, plus pointer |--------
| to first instruction | |
|-------------------------------| |
| |<-------
| |
............
| |
|-------------------------------|
| Final block - usually |
| has some extra room at |
| the end |
|_______________________________|
Virus patches this code to:
---------------------------------
| Header block - includes |
| total size, plus pointer |--------
| to first instruction | |
|-------------------------------| |
| |<--- |
| | | |
............ | |
| | | |
|-------------------------------| | |
| Final block - with virus code | | |
| in extra space at the end; |<--|----
| jumps to original entry point |----
|_______________________________|
On a microcomputer (e.g. MS/DOS or Macintosh), a similar patch can be made to the code of an OS service (e.g. the run-a-program service) both in memory and on disk.
Viruses look for other files to infect
Typically, when a virus is activated it tries to find other files to infect. (On a microcomputer, if the virus infects the run-a-program system service then it may go ahead and infect the program being run!)
While seemingly harmless, this can delay program start up quite a bit.
Of course, what is more serious is that the virus may do other things as well - perhaps on a "time bomb" basis.
Viruses are notoriously hard to stop once started
Protection
Typical methods used to detect viruses:
Against known viruses: look for tell-tale pattern in files
Against all viruses - use of program checksums, checked against copies stored in a safe place.
$Id: viruses.html,v 1.2 2000/04/16 23:34:05 senning Exp $
These notes were written by R. Bjork of Gordon College. They were edited, revised and converted to HTML by J. Senning of Gordon College in April 1998.