USENIX Association Proceedings of the 10th USENIX Security Symposium Washington, D.C., USA August 13–17, 2001 THE ADVANCED COMPUTING SYSTEMS ASSOCIATION © 2001 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. RaceGuard: Kernel Protection From Temporary File Race Vulnerabilities Crispin Cowan, Steve Beattie, Chris Wright, and Greg Kroah-Hartman WireX Communications, Inc. http://wirex.com/ Abstract This race condition becomes a security vulnerability if the victim program creating the temporary file is privi- Temporary file race vulnerabilities occur when privi- leged (i.e. running as root or some other privileged leged programs attempt to create temporary files in an user-ID) and the attacker creates a link pointing to a unsafe manner. “Unsafe” means “non-atomic with security sensitive file such as /etc/passwd or respect to an attacker’s activities.” There is no portable /etc/hosts.allow. When this occurs, the standard for safely (atomically) creating temporary files, open(O_CREAT) will obliterate the data contained in and many operating systems have no safe temporary file the sensitive file. The fopen() library function, being creation at all. As a result, many programs continue to a wrapper around open(O_CREAT), is similarly vul- use unsafe means to create temporary files, resulting in nerable. widespread vulnerabilities. This paper presents Race- Guard: a kernel enhancement that detects attempts to There are two commonly accepted mechanisms that exploit temporary file race vulnerabilities, and does so exist to prevent this race condition: using open() with with sufficient speed and precision that the attack can be the O_CREAT and O_EXCL flags, or using the halted before it takes effect. RaceGuard has been imple- mkstemp() library function (which is a wrapper mented, tested, and measured. We show that RaceGuard around open(O_CREAT|O_EXCL)). When is effective at stopping temporary file race attacks, pre- open(O_CREAT|O_EXCL) is called on a file that serves compatibility (no legitimate software is broken), already exists, it will fail and prevent the race attack. and preserves performance (overhead is minimal). Unfortunately, because these mechanisms are not ubiq- uitously available and portable, common programs 1 Introduction (such as Apache [3, 13]) still continue to use Attacks exploiting concurrency problems (“race vulner- mktemp() and friends, despite the fact that the Linux abilities”) are nearly as old as the study of computer sys- mktemp man page says “Never use mktemp().” tem security [1, 5]. These are called TOCTTOU (“Time of Check To Time Of Use”) errors [6]. Of particular This paper presents RaceGuard: a kernel enhancement interest is the temporary file creation vulnerability: pro- that detects attempts to exploit temporary file race vul- grams seeking to create a temporary file first check to nerabilities, and does so with sufficient speed and preci- see if a candidate file name exists, and then proceed to sion that the attack can be halted before it takes effect. create that file. The problem occurs if the attacker can RaceGuard functions by detecting the change in circum- race in between the file existence check and the file cre- stances between the stat() call and the open() call. If the ation, and the attacker creates the file that the victim stat() “fails” (the file does not exist), then RaceGuard program expected to create. caches the file name. If a subsequent open() call pro- vides the same name, and discovers that the file does In concrete terms, this problem occurs on UNIX systems exist, then RaceGuard detects a race attack, and aborts when programs use stat() or lstat() to probe for the open() operation. the existence of files, and open(O_CREAT) to create the files. An encapsulated means to create temporary The rest of this paper is organized as follows.Section 2 names is the mktemp() library function.1 The elaborates on the temporary file vulnerability issue. Sec- mktemp() library function simply encapsulates the tion 3 presents the RaceGuard design and implementa- lstat() call, and thus mktemp() followed by tion. Section 4 presents our security testing against open(O_CREAT) is vulnerable to race attacks. known race vulnerabilities in actively used software. Section 5 presents our compatibility testing, showing that RaceGuard protection does not interfere with nor- mal system operations. Section 6 presents our perfor- 1. and related library functions tmpnam() and tempnam(). mance testing, showing that the performance costs of This work supported in part by DARPA contract N66001-00-C-8032. RaceGuard protection are minimal. Section 7 describes Guard algorithm. Section 3.2 describes the RaceGuard related work in defending against temporary file race implementation and the cache management policy. vulnerabilities. Section 8 presents our conclusions. 3.1 RaceGuard Design 2 Temporary File Race Vulnerabilities RaceGuard seeks to detect pertinent changes in the file The basic form of a temporary file race vulnerability is system between the time an application probes for a that a privileged program first probes the state of the file nominated temporary file name, and the time the file is system, and then based on the results of that probe, takes actually created. “Pertinent” means changes with some action. The attacker can exploit the vulnerability respect to the nominated name. The RaceGuard algo- by “racing” between the probe and the action to change rithm to achieve this is as follows: the state of the file system in some critical way, such that the victim program’s action will have an unintended • Each process keeps a cache of potential temporary effect. file races. This cache is a list of file names, associ- ated with each process control block within the ker- The simple form of this attack is temporary file creation. nel. The victim program seeks to create a temporary file, • If file probe result is “non-existent file,” then cache probes for the existence of the file, and if the nominated the file name in the process’s RaceGuard cache. file name is not found, proceeds to create the file. The • If file creation hits a file that already exists, and the attacker exploits this by creating either a symbolic link name matches a name in the RaceGuard cache, then that matches the name of the file about to be created, this is a race attack: abort the open attempt. and points to a security sensitive file. The result is that • If file creation succeeds without conflicts, and the victim program will unwittingly over-write the secu- matches a name in the RaceGuard cache, then clear rity sensitive file with unintended content. that entry from the cache. This prevents “false posi- tive” RaceGuard events when a program uses the A variation on this scheme is the “dangling symlink”. same name for a file more than once. The victim program performs the same sequence as This caching mechanism serves to detect and differenti- above. The attacking program races in and creates a ate between the sequence “probe; create”, and “probe; symlink or hard link from the matching name to a non- attacker meddling; create”. To defend against the “dan- existent file whose existence has security implications, gling symlink” variant attack described in Section 2, such as /etc/hosts.allow or /etc/nologin. RaceGuard does two resolves on the name provided to open that are in the RaceGuard cache: the first follows Another variation is the “file swap.” Here the victim symlinks, while the second does not. If the two resolve program is a SUID root program that can be asked to differently, and the argument name matches an entry in write to a specific file [6]. The victim program defen- the RaceGuard cache, then this is treated as a race sively checks to see if the requesting user has access to attack. the file, and then only does the write if the user has per- mission. The attacker provides a file that they have RaceGuard does not defend against the “file swap” access, to, and between the access check and the write attack. Because the attack concerns an already existent operation, the attacker swaps the file for a symlink file, this is not really a temporary file race attack. In pointing to a security sensitive file. practice, such vulnerabilities appear to be relatively rare: searching Securityfocus.com’s vulnerability data- 3 RaceGuard: Dynamic Protection from base [18] for “race” produced 75 hits, while searching Race Attacks for “race & !tmp & !temp” produced only 24 hits. Even among the 24, random sampling indicates that many of RaceGuard detects attempts to exploit race vulnerabili- them are actually temporary file issues, but did not say ties at run time by detecting a change in the environment so in the name of the vulnerability. between the time the program probes for the existence of a file, and the time it tries to create it: if the file 3.2 RaceGuard Implementation & Cache named “foo” does not exist at the time of the stat, but does exist at the time of the open, then someone tried to Management Policy race us, so abort the operation. RaceGuard achieves this The RaceGuard implementation is in the kernel, facili- by caching the file names that are probed, and when cre- tating both per-process and inter-process RaceGuard ation attempts occur that hit existing files, the names are cache management. RaceGuard mediates three basic compared to the cache. Section 3.1 describes the Race- types of system calls: • those which can inform the program that a file sys- 3.