EXAMPLE: Consider the isolated system that the development network administrators use to create the CD-ROM from which other workstations boot (see Section 27.7.2). This system is kept in a locked room, and only the authorized users of the system have keys. The system is not connected to networks or telephone lines and can be accessed only from within that room. The password for the role account used to construct the CD-ROM is written on a whiteboard in the room. Given that all users of the isolated system are authorized to know that password, and that anyone else entering the room is under observation, this arrangement meets policy component U1. (But see Exercise 1.)

EXAMPLE: The development network has 10 infrastructure systems (mail, file, Web, and other servers). Anne and Paul are the lead system administrators for the infrastructure systems. They must have privileged access to all those systems. To make the root and Administrator passwords as difficult as possible to guess, those passwords are chosen randomly. But Paul and Anne cannot remember 10 random passwords. Instead, each has decided on a transformation algorithm.^[3] Anne's is “Change the third letter's case, and delete the last character.” Paul's is “Add 2 mod 10 to the first digit, and delete the first letter.” The following table summarizes the actual passwords and what Paul and Anne have written on small pieces of paper that they carry with them.

If someone obtains either Anne's or Paul's list, the thief will not be able to determine the correct password before Anne or Paul notices that the list is missing and takes appropriate action.

EXAMPLE: The third verse of the nonsense poem Jabberwocky [176] is

Marilyn, a developer at the Drib, chose her password by taking the first letter of the second and fourth words from each line and putting an “&” between them. Her password is “ttrs&vmbi.”

EXAMPLE: Students at many university sites in the 1970s tried this attack in public terminal rooms. They had varying degrees of success. An early version of one operating system had a feature that defeated the crude versions of this attack. If a user mistyped his name or password, the login program would reprompt him for this information. However, the prompt for the user name would change from “Login:” to “Name:”. If a user saw the prompt “Login:” twice in a row, he had reason to believe that a spoof was underway.

EXAMPLE: Secure Xenix [398] had an alternative approach that is common to systems that desire high assurance authentication of users. When a user wished to log in, he struck a particular combination of keys that created a trusted path to the kernel. No application program could disable this feature; no application program could read or alter the information given to the kernel over that path. The kernel then performed the identification and authentication processing and granted or denied the user access.

EXAMPLE: “Shoulder surfing” is a technique in which an attacker watches the target enter the password. Variations on this attack include reading of the characters from kernel variables, which requires that the attacker have access to those structures (usually as a result of a system configuration error^[7] ), and passive wiretapping of an unenciphered connection.

The latter opportunity for reading the password is important. Many protocols, such as ftp and telnet, do not encipher messages. If a user name and password are sent over such a connection, they are visible at every intermediate node and network. Other protocols, such as SSH and SSL, provide enciphered “tunnels” through which other protocols can be sent.^[8] This provides the user with confidentiality even when the protocols themselves do not. In some environments, this is unnecessary. For example, the Drib firewalls block any traffic to the Internet, and hosts and networks within the Drib are trusted not to capture network traffic. In other environments, especially when messages are sent over untrusted links, enciphering of all messages is prudent.

EXAMPLE: Suppose a user logs in from the console. After the login, the system prints a message indicating that she last successfully logged in on the previous Tuesday and was currently using a network terminal. The time of login happens to be correct, but the terminal is not, and the user should contact the system administrator. One possible explanation is that a Trojan horse is capturing all commands, saving them in a file, and then passing the commands back to the normal system login process over a network connection.

EXAMPLE: The X window system provides a program called xlock. When run, xlock blocks access to the monitor until the user's password is entered. Only the user or the system administrator can terminate the program without the password by sending an appropriate termination signal to it from another session.

EXAMPLE: In one version of the UNIX operating system, the lock program prompted the user for a password and then locked access to the terminal until the password was entered. If the user forgot the password, the master password “Hasta la vista!” would unlock the terminal. (See Exercise 2.)

EXAMPLE: The author once accessed a UNIX system through a modem to make some changes in his role as a system administrator. Unfortunately, the configuration of the system had changed so that he was unable to acquire superuser privileges. One not only needed the password but also had to be a member of the group wheel.^[14] The author logged out and hung up. When he accessed the system 20 minutes later, through the same modem bank, the modem connected him to an ongoing session. This session, left when a previous user had hung up without logging out, had super-user privileges. The author made the required changes, sent electronic mail to warn everyone to log out before disconnecting, and then logged out and hung up the telephone. The next day, he checked the modem configurations and reset the switch that detected carrier drop. (It had been bumped accidentally when someone was adding two new modems to the rack of modems.)

EXAMPLE: Peter is using a UNIX-based system. He wants to allow Deborah to read the file design but prevent other users from doing so. He can use the abbreviated ACL mechanism of standard UNIX systems^[16] to do this in three ways.

If Deborah and Peter are the only members of a group, Peter can make the file owned by that group and readable by that group but not readable by others.

If Deborah is the only member of a group and the UNIX system semantics allow the owner of a file to give the file to a group of which the owner is not a member, Peter can give group ownership of the file to Deborah's group and then set the group ownership privileges as described above.

An alternative approach is to set permissions on the containing directory. Peter can set the permissions of the directory to allow search access only to himself and to the group of which Deborah is the only member by turning on read and execute permission for the group owner of the directory. Then the protections of the file can allow anyone to read the file. Because only Peter and Deborah can search the directory (the execute permission), only they can reach the file.

EXAMPLE: The Windows NT access control lists^[17] allow Peter to give Deborah access directly. Peter creates an ACL for design with two entries:

(Peter, full control) (Deborah, read)

The semantics of Windows NT disallow access to any user or group omitted from the ACL. Hence, only Peter and Deborah can access the file.

EXAMPLE: Suppose Mona Anne wants to copy the file xyzzy on a UNIX system. She gives the following command.

cp xyzzy plugh

If the file plugh does not exist, this command creates it and copies the contents of xyzzy into it. The permissions will be the same as for xyzzy, except that the setuid and setgid attributes will be discarded (see Section 28.4.5).

If the file plugh exists, the command copies the contents of xyzzy into it. It does not alter the permissions of plugh. This is a security problem, because if xyzzy is not readable by everyone but plugh is, the contents of xyzzy will no longer be confidential because anyone reading plugh will learn them.

EXAMPLE: Now Mona Anne decides to move the file plugh to another directory. She gives the command

mv plugh /usr/monaanne/advent

If the directory resides in the same file system, the direct alias is deleted from the current directory and placed in the directory /usr/monaanne/advent. Otherwise, the mv command executes:

cp plugh /usr/monaanne/advent/plugh
rm plugh

In the first case, the permissions of plugh are preserved. In the second, those permissions may be changed, as noted above.

EXAMPLE: Scout wants to delete all the files in her directory whose names end in the characters “.o”. She uses the pattern “*.o” to match these file names. The “*” is a wildcard that matches 0 or more characters, so the pattern is read as “all file names that end in .o”. Unfortunately, she mistypes the command, putting a space between the “*” and the “.o” accidentally:

rm * .o

This command says to delete all files in the current directory, and the file “.o”. Scout will discover this when the command prints the error message

.o: No such file or directory

after all the files have been deleted.

EXAMPLE: PGP protects a user's private key by enciphering it with a pass-phrase. Mary Ann receives a letter that the sender has enciphered for confidentiality using PGP. She enters her pass-phrase to allow the PGP deciphering program to obtain her private key. It uses her key to decipher the data encryption key, and then the message. Unknown to Mary Ann, Eve has broken into her system and has implanted a keystroke recording module. When Eve retrieves the log of the session, she will have the pass-phrase, from which she can obtain Mary Ann's private key, and thus her identity (as far as Mary Ann's PGP recipients are concerned).

EXAMPLE: An implementation of the ftp client under some versions of the UNIX system allows users to keep account names, host names, and passwords in a file called .netrc. Kathy uses the remote host gleep to store files, so she often connects using ftp. Her .netrc file looks like this:

machine gleep
login kathy
password oi4ety98

The security risks of keeping her information in this file were brought home when one day ftp ignored the file. On investigation, Kathy determined that the .netrc file was readable by all users on the system. By looking at her previously typed commands, Kathy realized that she had mistyped one of them. The unfortunate effect of that command was to make the .netrc file readable.

EXAMPLE: When a user logs in to a FreeBSD 4.4 system, her login shell sh initializes itself by accessing start-up information in the following order.

If any of these files do not exist, the step is skipped.

The security threat lies in the program's trust of the start-up information. For example, if the environment variable ENV were to name a file that an untrusted user could alter, then that user could insert commands to delete files or give the attacker privileges to perform actions that violate policy. This Trojan horse can be difficult to detect, especially because it can erase itself after execution but before the shell allows interaction.

EXAMPLE: Part of Toni's job as a secretary to the manager of the Drib Development Group is to read mail sent to her boss, Fran. Because Fran knew about the dangers of sharing passwords, she copied the UNIX command interpreter into a file that she owned, and turned on the setuid permission.^[34] This allowed Toni to read Fran's mail.

Toni quickly discovered that the command interpreter allowed her to do anything as Fran. She suggested to Fran that perhaps some other approach could be found.^[35] After some discussion, the two decided to forward to Toni a copy of every letter that Fran received. This enabled Toni to process Fran's mail without having access to her account.

The two had considered an alternative approach—to make a copy of the mail reading program setuid to Fran. Unfortunately, the mail program had an escape mechanism that allowed the user to pass commands to a command interpreter—and that had the same effect as giving Toni the shell.

EXAMPLE: Johannes' coworker wants to see Johannes' confidential designs. The coworker has created a small program called ls that will copy the designs to a public area, from which the coworker can retrieve them. She has placed copies of ls in various publicly writable directories, including /tmp. Johannes changed to that directory to clean up files he had left there. Johannes' program search path was

. /bin /usr/bin /usr/local/bin

where “.” means the current directory. Johannes executed the ls program. The command interpreter first looked in the current directory for an executable named ls, found it, and executed it. The coworker got the desired files.

EXAMPLE: The NIMDA worm [229] used several methods to propagate itself. One method involved the use of e-mail. The worm would mail itself to a user on the target system, encapsulated as an attachment to a letter. When the user opened the letter, the default configuration of the mail programs involved would pass the attachment to another program to be displayed. The other program would execute the code comprising the worm, thereby infecting the system.

EXAMPLE: Someone pretending to be a Microsoft employee obtained two certificates that could be used to sign programs under the name of Microsoft Corporation [228].^[40] The issuer (not Microsoft Corporation) immediately revoked both certificates and placed them on the Certificate Revocation List,^[41] but sites that had not received the revocation notice would accept the certificates as valid and could execute malicious logic that the attackers had signed. Although the mechanism involved used Web pages, the generalization to electronic mail is obvious.

EXAMPLE: A sales director once sent her sales team a chart showing the effects of a proposed reorganization. Unfortunately, she did not realize that the spreadsheet in which she had created the chart also contained confidential information such as names and addresses, salaries, and personal comments about each employee. The information disrupted the efficiency of the sales force. [47]