Where Do You Want to Go Today? Escalating
Total Page：16
File Type：pdf, Size：1020Kb
Where Do You Want to Go Today? ∗ Escalating Privileges by Pathname Manipulation Suresh Chari Shai Halevi Wietse Venema IBM T.J. Watson Research Center, Hawthorne, New York, USA Abstract 1. Introduction We analyze filename-based privilege escalation attacks, In this work we take another look at the problem of where an attacker creates filesystem links, thereby “trick- privilege escalation via manipulation of filesystem names. ing” a victim program into opening unintended files. Historically, attention has focused on attacks against priv- We develop primitives for a POSIX environment, provid- ileged processes that open files in directories that are ing assurance that files in “safe directories” (such as writable by an attacker. One classical example is email /etc/passwd) cannot be opened by looking up a file by delivery in the UNIX environment (e.g., [9]). Here, an “unsafe pathname” (such as a pathname that resolves the mail-delivery directory (e.g., /var/mail) is often through a symbolic link in a world-writable directory). In group or world writable. An adversarial user may use today's UNIX systems, solutions to this problem are typ- its write permission to create a hard link or symlink at ically built into (some) applications and use application- /var/mail/root that resolves to /etc/passwd. A specific knowledge about (un)safety of certain directories. simple-minded mail-delivery program that appends mail to In contrast, we seek solutions that can be implemented in the file /var/mail/root can have disastrous implica- the filesystem itself (or a library on top of it), thus providing tions for system security. Other historical examples involve protection to all applications. privileged programs that manipulate files under the world- writable /tmp directory [11], or even in a directory of the Our solution is built around the concept of pathname attacker's choice [10]. manipulators, which are roughly the users that can influ- Over time, privileged programs have implemented safety ence the result of a file lookup operation. For each user, we mechanisms to prevent pathname resolution attacks. These distinguish unsafe pathnames from safe pathnames accord- mechanisms, however, are tailored specifically to the pro- ing to whether or not the pathname has any manipulators gram's purpose, are typically implemented in the program other than that user or root. We propose a safe-open itself, and rely on application-specific knowledge about the procedure that keeps track of the safety of the current path- directories where files reside. We believe, however, that the name as it resolves it, and that takes extra precautions while application is fundamentally the wrong place to implement opening files with unsafe pathnames. We prove that our so- these safety mechanisms. lution can prevent a common class of filename-based privi- Recent vulnerability statistics support our position. The lege escalation attacks, and describe our implementation of US National Vulnerability Database [16] lists at least 177 the safe-open procedure as a library function over the entries, since the start of 2008, for symlink-related vulnera- POSIX filesystem interface. We tested our implementation bilities that allow an attacker to either create or delete files, on several UNIX variants to evaluate its implications for or to modify the content or permissions of files. No doubt, systems and applications. Our experiments suggest that this the vast majority of these entries are due to application writ- solution can be deployed in a portable way without break- ers who simply were not aware of the problem. However, ing existing systems, and that it is effective against this class there are even vulnerabilities in system programs, which of pathname resolution attacks. are typically better scrutinized. For example, an unsafe file open vulnerability was reported in the inetd daemon in Solaris 10 [12] when debug logging is enabled. This daemon runs with root privileges and logs debug mes- ∗ This work was supported in part by the Department of Homeland Se- sages to the file /var/tmp/inetd.log if that file ex- curity under grant FA8750-08-2-0091. ists. The file is opened using fopen(DEBUG LOG FILE, "r+"). Since /var/tmp is a world writable directory (such as access/open races [20, 4]). Rather, we directly ad- a local unprivileged user can create a link to any file on dresses the privilege-escalation threat, which is the main the system, and overwrite that file as root with inetd motivation for many of these attacks. Here we focus on the debug messages. A similar example, related to unsafe pathname resolution mechanism, identify a simple security unlink operation, is a reported vulnerability in the Linux property that can be met even in the presence of race con- rc.sysinit script [13] in the initscripts package ditions, and show that this property can be used to prevent before version 8.76.3-1. That vulnerability could be used privilege-escalation attacks. by unprivileged users to delete arbitrary files by creating symbolic links from specific user-writable directories. 1.1. Our contribution In addition to these examples, experiments that we run in the course of this work uncovered a number of (latent) We focus on tightening the connection between files and privilege escalation vulnerabilities, where system processes their names. In most filesystems, programs access files by write or create files as root in directories that are writable providing names (the pathnames), and rely on the filesys- by unprivileged system process. In these cases, a com- tem to resolve these names into pointers to the actual files promise of the unprivileged system process could result in (the file handles). Unfortunately, the relation between files further privilege escalation. These vulnerabilities are de- and their names in POSIX filesystems is murky: Files can scribed in Section 5.3. have more than one name (e.g., due to hard or symbolic These examples demonstrate that it is unrealistic to ex- links), these names can be changed dynamically (e.g., by pect every application (or even every “important applica- renaming a directory), filename resolution may depend on tion”) to implement defenses against these attacks. We con- the current context (e.g., the current working directory), etc. tend that a system-level safety net would be more effective This murky relation obscures the semantics of the name-to- at stopping these problems than trying to fix every affected file translation, and provides system administrators and ap- application, or trying to educate current and future gener- plications writers with ample opportunities to introduce se- ations of application writers. In a world where applica- curity vulnerabilities. Our solution builds on the following tions (and their fragments) are used in environments that concepts: are vastly different from what the application designers had in mind, it is unreasonable to expect that the applications • themselves will distinguish between files that are safe to Ignoring the partition to directories and subdirectories, open and ones that are not. we view the entire path as just one name and examine In this work we seek a general-purpose mechanism that its properties. We introduce the concept of the ma- can be implemented in the file system or in a system library, nipulators of a name, which roughly captures “anyone that allows programs to open files that exist in an “unsafe” who can change the outcome of resolving that name.” environment, knowing that they will not be “tricked” into In POSIX filesystems, the manipulators of a path are opening files that exist in a “safe” environment. Specifi- roughly the users and groups that have write permis- cally, we show how such a mechanism can be implemented sion in any directory along this path. More precisely, over POSIX filesystems. U belongs to the manipulators of a name if the reso- lution of that name visits any directory that is either In a nutshell, our solution can be viewed as identifying owned by U or that U has write permissions for. “unsafe subtrees” of the filesystem directory tree, and tak- ing extra precautions whenever we visit any of them during • Using the concept of manipulators, we distinguish be- the resolution of a pathname. Roughly, a directory is unsafe tween safe names and unsafe names. Roughly, a name for a certain user if anyone other than that user (or root) is safe for some user if only that user can manipu- can write in it. Our basic solution consists of resolving a late it. Specializing this concept to UNIX systems, pathname component by component, enforcing the condi- we call a name “system safe” if its only manipula- tions that once we visit an unsafe node, in the remainder tor is root, and call it “safe for U” if the only ma- of the path we will no longer follow symbolic links or al- nipulators of it are root and U. For example, typi- low pathname elements of `..', nor will we open a file that cally the name /etc/passwd is “system safe”, the has multiple hardlinks. Thus, once we resolve through an name /home/joe/mbox is safe for user joe, and unsafe node, we will not visit nodes that exist outside the the name /var/mail/jane is not safe for anyone subtree rooted at that node.1 (as /var/mail is group or world writable). In contrast with many prior works on filename-based at- tacks, our work is not primarily focused on race conditions • Once we have safe and unsafe pathnames, we can state 1We describe in Section 6.1 a more permissive variant that still provides our main security guarantee. We provide a procedure the same protection against privilege-escalation attacks. safe-open that ensures the following property: If a file has safe names for user U, then a more formal analysis with experimental validation was safe-open will not open it for U using done by Bishop and Dilger [2].