TL;DR: The Rewriter Module as discussed by the authors provides a mechanism for modifying an executable upon first execution, such as attaching a unique serial number, encrypting or decrypting the executable, or adding protection code (license enforcement code) to the executable.
Abstract: The present invention, generally speaking, provides a mechanism for modifying an executable upon first execution. Various modifications may be made to the executable, including modifications useful for purposes of electronic software distribution, such as attaching a unique serial number, encrypting or decrypting the executable, or adding protection code (license enforcement code) to the executable. A Rewriter Module performs the actual modification. First, a copy of the executable is made. The copy is then run and the original executable is deleted. Then a second copy of the executable is made using the name of the original executable, and the first copy is deleted. During one or both of the copying steps, modifications are made to the executable. The modifications may be modifications useful for purposes of electronic software distribution, especially Try/Buy. When a software product is purchased, the foregoing process may be reversed, leaving the executable in its original "pristine" condition. All of the foregoing activity is transparent to the user.
TL;DR: It is proved the "folk theorem" that no portable, deterministic solution exists without changes to the system call interface, a probabilistic solution is presented, and the effect of increasing CPU speeds on the exploitability of the attack is examined.
Abstract: It is well known that it is insecure to use the access(2) system call in a setuid program to test for the ability of the program's executor to access a file before opening said file. Although the access(2) call appears to have been designed exactly for this use, such use is vulnerable to a race condition. This race condition is a classic example of a time-of-check-to-time-of-use (TOCTTOU) problem. We prove the "folk theorem" that no portable, deterministic solution exists without changes to the system call interface, we present a probabilistic solution, and we examine the effect of increasing CPU speeds on the exploitability of the attack.
TL;DR: The Tester's Assistant is introduced, a collection of tools to mechanize the process of testing security-related C programs, and it is shown that a slice of a privileged program (rdist) with respect to its security specifications is quite small.
Abstract: Addresses the problem of testing security-relevant software, especially privileged (typically, setuid root) and daemon programs in UNIX. The problem is important, since it is these programs that are the source of most UNIX security flaws. For some programs, such as the UNIX sendmail program, new security flaws are still being discovered, despite being in use for many years. For special-purpose systems with fewer users, flaws are likely to remain undiscovered for even longer. Our testing process is driven by specifications we create for the privileged programs. These specifications simultaneously define the allowed behavior far these programs and identify problematic system calls, regions where the program is vulnerable, and generic security flaws. The specifications serve three roles in our testing methodology: as criteria against which a program is sliced, as oracles against which it is tested, and as a basis for generating useful tests. Slicing is employed to significantly reduce the size of the program to be tested. We show that a slice of a privileged program (rdist) with respect to its security specifications is quite small. We introduce the Tester's Assistant, a collection of tools to mechanize the process of testing security-related C programs. >
TL;DR: How to write setuid programs to make using them to compromise a UNIX system as difficult as possible is discussed.
Abstract: UNIX† systems allow certain programs to grant privileges to users temporarily; these are called setuid programs. Because they explicitly violate the protection scheme designed into UNIX, they are among the most difficult programs to write. This paper discusses how to write these programs to make using them to compromise a UNIX system as difficult as possible. Introduction A typical problem in systems programming is often posed as a problem of keeping records [1]. Suppose someone has written a program and wishes to keep a record of its use. This file, which we shall call the history file, must be writable by the program (so it can be kept up to date), but not by anyone else (so that the entries in it are accurate.) UNIX solves this problem by providing two sets of identifications for processes. The first set, called the real user identification and group identification (or UID and GID, respectively), indicate the real user of the process. The second set, called the effective UID and GID, indicate what rights the process has, which may be, and often are, different from the † UNIX is a trademark of Bell Laboratories.