Fig 2 - uploaded by Steve Chapin
Content may be subject to copyright.
Three ways of interpreting a TOCTTOU binding flaw with multiple use operations. (a) Three consecutive programming conditions (use1 is the implicit check operation of the use2, and use2 is the implicit check operation of the use3). (b) Three overlapping programming conditions, where all the use operations share the common check operation. (c) One programming condition with multiple use operations. This is our definition of the TOCTTOU binding flaw.
Source publication
![Fig. 1 (a) A binding flaw found in xterm [19] (derived from [1]). (b) A...](profile/Steve-Chapin-3/publication/220066924/figure/fig1/AS:668992398176257@1536511625029/a-A-binding-flaw-found-in-xterm-19-derived-from-1-b-A-binding-flaw-found-in_Q320.jpg)
Multiprocessing environments such as Unix are susceptible to race conditions on the le space, since processes share les in the system. A process accessing a le may get unexpected results while executing in a critical section, if the binding between the le name and the le object is altered by another process. Such errors, called Time-of-check-to-tim...
Contexts in source publication
Context 1
... programming condition is the existence of an in- terval between two file operations that refer to the same file object, where the second depends on one or more assumptions from the result of the first. Note that our definition of the TOCTTOU binding flaw (given in section 2.1) is more general than the programming condition defined above, in that we in- clude TOCTTOU binding flaws with multiple use operations; such cases may be interpreted in three ways, illustrated in Figure 2. Our definition of the TOCTTOU binding flaw is equivalent to (c) in Fig- ure 2, which is an extended definition of program- ming conditions, and can have multiple use oper- ations. ...
Context 2
... programming condition is the existence of an in- terval between two file operations that refer to the same file object, where the second depends on one or more assumptions from the result of the first. Note that our definition of the TOCTTOU binding flaw (given in section 2.1) is more general than the programming condition defined above, in that we in- clude TOCTTOU binding flaws with multiple use operations; such cases may be interpreted in three ways, illustrated in Figure 2. Our definition of the TOCTTOU binding flaw is equivalent to (c) in Fig- ure 2, which is an extended definition of program- ming conditions, and can have multiple use oper- ations. It yields the least number of programming conditions in the program. ...
Citations
... Lhee and Chapin [51] proposed another software library that intercepts system calls to detect TOCTOU vulnerabilities, detecting inconsistencies in file objects by means of their binding information (specifically, the inode and the filename). This solution is implemented as a kernel module for Red Hat Linux 7.3 running on top of Linux kernel version 2.4.18. ...
File-based
Time-of-Check to Time-of-Use
(TOCTOU) race conditions are a well-known type of security vulnerability. A wide variety of techniques have been proposed to detect, mitigate, avoid, and exploit these vulnerabilities over the past 35 years. However, despite these research efforts, TOCTOU vulnerabilities remain unsolved due to their non-deterministic nature and the particularities of the different filesystems involved in running vulnerable programs, especially in Unix-like operating system environments. In this paper, we present a systematic literature review on defense and attack techniques related to the file-based TOCTOU vulnerability. We apply a reproducible methodology to search, filter, and analyze the most relevant research proposals to define a global and understandable vision of existing solutions. The results of this analysis are finally used to discuss future research directions that can be explored to move towards a universal solution to this type of vulnerability.
... These defenses have often been focused on TOCTTOU attacks [8,34]. Some defenses are implemented in the program or as library extensions [15,16,37,47] and some as kernel extensions [12,36,38,44,48,49], but the methods overlap, where some enforce invariants on file access [15,37,38,44,48,49], some enforce namespace invariants [12,36], and some aim for "safe" access methods [16,47]. In general, all program defenses have been limited because they lack insight into the changing system and all system defenses are limited because they lack side-information about the intent of the program [11]. ...
... These defenses have often been focused on TOCTTOU attacks [8,34]. Some defenses are implemented in the program or as library extensions [15,16,37,47] and some as kernel extensions [12,36,38,44,48,49], but the methods overlap, where some enforce invariants on file access [15,37,38,44,48,49], some enforce namespace invariants [12,36], and some aim for "safe" access methods [16,47]. In general, all program defenses have been limited because they lack insight into the changing system and all system defenses are limited because they lack side-information about the intent of the program [11]. ...
Android filesystem access control provides a foundation for Android system integrity. Android utilizes a combination of mandatory (e.g., SEAndroid) and discretionary (e.g., UNIX permissions) access control, both to protect the Android platform from Android/OEM services and to protect Android/OEM services from third-party apps. However, OEMs often create vulnerabilities when they introduce market-differentiating features because they err when re-configuring this complex combination of Android policies. In this paper, we propose the PolyScope tool to triage the combination of Android filesystem access control policies to vet releases for vulnerabilities. The PolyScope approach leverages two main insights: (1) adversaries may exploit the coarse granularity of mandatory policies and the flexibility of discretionary policies to increase the permissions available to launch attacks, which we call permission expansion, and (2) system configurations may limit the ways adversaries may use their permissions to launch attacks, motivating computation of attack operations. We apply PolyScope to three Google and five OEM Android releases to compute the attack operations accurately to vet these releases for vulnerabilities, finding that permission expansion increases the permissions available to launch attacks, sometimes by more than 10X, but a significant fraction of these permissions (about 15-20%) are not convertible into attack operations. Using PolyScope, we find two previously unknown vulnerabilities, showing how PolyScope helps OEMs triage the complex combination of access control policies down to attack operations worthy of testing.
... By changing the content of a memory location that is passed to the operating system, the content of a file could be altered after a validity check [4,8,72]. Especially time-ofcheck-to-time-of-use bugs in the file system are well-studied, and several solutions have been proposed [13,42,57,58,68]. ...
Double-fetch bugs are a special type of race condition, where an unprivileged execution thread is able to change a memory location between the time-of-check and time-of-use of a privileged execution thread. If an unprivileged attacker changes the value at the right time, the privileged operation becomes inconsistent, leading to a change in control flow, and thus an escalation of privileges for the attacker. More severely, such double-fetch bugs can be introduced by the compiler, entirely invisible on the source-code level. We propose novel techniques to efficiently detect, exploit, and eliminate double-fetch bugs. We demonstrate the first combination of state-of-the-art cache attacks with kernel-fuzzing techniques to allow fully automated identification of double fetches. We demonstrate the first fully automated reliable detection and exploitation of double-fetch bugs, making manual analysis as in previous work superfluous. We show that cache-based triggers outperform state-of-the-art exploitation techniques significantly, leading to an exploitation success rate of up to 97%. Our modified fuzzer automatically detects double fetches and automatically narrows down this candidate set for double-fetch bugs to the exploitable ones. We present the first generic technique based on hardware transactional memory, to eliminate double-fetch bugs in a fully automated and transparent manner. We extend defensive programming techniques by retrofitting arbitrary code with automated double-fetch prevention, both in trusted execution environments as well as in syscalls, with a performance overhead below 1%.
... By changing the content of a memory location that is passed to the operating system, the content of a file could be altered after a validity check [4,8,72]. Especially time-ofcheck-to-time-of-use bugs in the file system are well-studied, and several solutions have been proposed [13,43,58,68]. ...
Double-fetch bugs are a special type of race condition, where an unprivileged execution thread is able to change a memory location between the time-of-check and time-of-use of a privileged execution thread. If an unprivileged attacker changes the value at the right time, the privileged operation becomes inconsistent, leading to a change in control flow, and thus an escalation of privileges for the attacker. More severely, such double-fetch bugs can be introduced by the compiler, entirely invisible on the source-code level. We propose novel techniques to efficiently detect, exploit, and eliminate double-fetch bugs. We demonstrate the first combination of state-of-the-art cache attacks with kernel-fuzzing techniques to allow fully automated identification of double fetches. We demonstrate the first fully automated reliable detection and exploitation of double-fetch bugs, making manual analysis as in previous work superfluous. We show that cache-based triggers outperform state-of-the-art exploitation techniques significantly, leading to an exploitation success rate of up to 97%. Our modified fuzzer automatically detects double fetches and automatically narrows down this candidate set for double-fetch bugs to the exploitable ones. We present the first generic technique based on hardware transactional memory, to eliminate double-fetch bugs in a fully automated and transparent manner. We extend defensive programming techniques by retrofitting arbitrary code with automated double-fetch prevention, both in trusted execution environments as well as in syscalls, with a performance overhead below 1%.
... There are varieties of shared objects in any computer system, such as files [2], sockets [36] and memory locations [39], therefore, a TOCTOU can exist in different layers throughout the system. TOCTOU race conditions often occur in file systems and numerous approaches [5,9,18,4,27] have been proposed to solve these problems, but there is still no general, secure way for applications to access file systems in a race-free way. ...
We present the first static approach that systematically detects potential double-fetch vulnerabilities in the Linux kernel. Using a pattern-based analysis, we identified 90 double fetches in the Linux kernel. 57 of these occur in drivers, which previous dynamic approaches were unable to detect without access to the corresponding hardware. We manually investigated the 90 occurrences, and inferred three typical scenarios in which double fetches occur. We discuss each of them in detail. We further developed a static analysis, based on the Coccinelle matching engine, that detects double-fetch situations which can cause kernel vulnerabilities. When applied to the Linux, FreeBSD, and Android kernels, our approach found six previously unknown double-fetch bugs, four of them in drivers, three of which are exploitable double-fetch vulnerabilities. All of the identified bugs and vulnerabilities have been confirmed and patched by maintainers. Our approach has been adopted by the Coccinelle team and is currently being integrated into the Linux kernel patch vetting. Based on our study, we also provide practical solutions for anticipating double-fetch bugs and vulnerabilities. We also provide a solution to automatically patch detected double-fetch bugs.
... The accesses are concurrent (not synchronized) so they could happen simultaneously [12]. Race conditions may occur when shared data accesses are not synchronized properly and the execution result depends on the order of threads [3]. Access to shared memory data access is controlled by critical sections. ...
... All systems comprising multiprocessing environment are vulnerable to Race condition attack. Race condition is also known as Time of check/time of use (TOC/TOU) binding flaw, Concurrency attacks, or Threadjacking [3]. Typical race condition attacks involve opening a file, validating a file, running a subprogram, checking a password, or verifying a username. ...
... Several papers [1], [2], [3] have defined Race condition. The following work [4], [5], [7], [8] deal with race condition detection techniques. ...
The Race condition is a privilege vulnerability that manipulates the small window of time between appliance of a security control and use of services in a system. This vulnerability is a result of interferences caused by multiple threads running in the system and sharing the same resources. These processes might include trusted process such as operating system files and un-trusted processes. The race conditions vulnerability is one of the more common in UNIX-like systems, where directories /tmp and /var/tmp are shared between threads. A study of Race condition vulnerability is presented in this paper. Though Race condition could be found in various systems, this paper focuses on UNIX-like systems only.
... While a variety of system defenses for these attacks have been proposed, particularly for name resolution attacks based on race conditions [14,20,22,39,40,48,[50][51][52]57], researchers have found that such defenses are fundamentally limited by a lack of knowledge about the program [12]. Thus, the programmers' challenge is to find such vulnerabilities before adversaries do. ...
The process of name resolution, where names are resolved into resource references, is fundamental to computer science, but its use has resulted in several classes of vulnerabilities. These vulnerabilities are difficult for programmers to eliminate because their cause is external to the program: the adversary changes namespace bindings in the system to redirect victim programs to a resource of the adversary's choosing. Researchers have also found that these attacks are very difficult to prevent systematically. Any successful defense must have both knowledge about the system namespace and the program intent to eradicate such attacks. As a result, finding and fixing program vulnerabilities to such as attacks is our best defense. In this paper, we propose the STING test engine, which finds name resolution vulnerabilities in programs by performing a dynamic analysis of name resolution processing to produce directed test cases whenever an attack may be possible. The key insight is that such name resolution attacks are possible whenever an adversary has write access to a directory shared with the victim, so STING automatically identifies when such directories will be accessed in name resolution to produce test cases that are likely to indicate a true vulnerability if undefended. Using STING, we found 21 previously-unknown vulnerabilities in a variety of Linux programs on Ubuntu and Fedora systems, demonstrating that comprehensive testing for name resolution vulnerabilities is practical.
... Related work [15,28,35] often matches specific predefined pairs of system calls to identify potential races. DynaRace introduces a new mapping cache that keeps track of all accessed files; all file-related system calls are rewritten to use this new mapping cache. ...
... A dynamic approach can observe all system calls as they happen. These system calls can either be logged and analyzed postmortem [18] or an online analysis can evaluate the pair of system calls according to a given policy [28]. Aggarwal and Jalote [3] use static binary translation to add dynamic guards that are executed at runtime. ...
Time Of Check To Time Of Use (TOCTTOU) race conditions for file accesses in user-space applications are a common problem in Unix-like systems. The mapping between filename and inode and device is volatile and can provide the necessary preconditions for an exploit. Applications use filenames as the primary attribute to identify files but the mapping between filenames and inode and device can be changed by an attacker.
DynaRace is an approach that protects unmodified applications from file-based TOCTTOU race conditions. DynaRace uses a transparent mapping cache that keeps additional state and metadata for each accessed file in the application. The combination of file state and the current system call type are used to decide if (i) the metadata is updated or (ii) the correctness of the metadata is enforced between consecutive system calls.
DynaRace uses user-mode path resolution internally to resolve individual file atoms. Each file atom is verified or updated according to the associated state in the mapping cache. More specifically, DynaRace protects against race conditions for all file-based system calls, by replacing the unsafe system calls with a set of safe system calls that utilize the mapping cache. The system call is executed only if the state transition is allowed and the information in the mapping cache matches.
DynaRace deterministically solves the problem of file-based race conditions for unmodified applications and removes an attacker's ability to exploit the TOCTTOU race condition. DynaRace detects injected alternate inode and device pairs and terminates the application.
... L'approche la plus connue est celle de Ko et Redmond qui permet de détecter les failles à posteriori [Ko and Redmond, 2002]. De nombreuses autres propositions [Lhee and Chapin, 2005], [Joshi et al., 2005] ont suivi reprenant le même principe ; Protection Dynamique Si on se contente de détecter la concurrence, il est possible de suspendre (ou tuer) les processus ou des appels systèmes suspects. Ainsi, le système [Cowan et al., 2001, Tsyrklevich and Yee, 2003, Uppuluri et al., 2005 peut être protégé ; ...
The subject of this thesis is to propose an in-depth protection that can be enforced by the operating system. First, we present that current security solutions are weak in the expression of security. Indeed, most of them support only one security properties. We introduce a language that allows to formalize a large set of security properties. This language expresses directs and transitives system activities. It allows to formalize the majority of integrity and confidentiality security properties introduced in the litterature. Moreover, the language can also expresses dynamic security properties. We introduces a new dynamic security model for the protection of multiple security domains managed by a web browser. We define a method to compil our language. The purpose is to analyze the system call done by the users processes. The compilation process build and analyze an information flow graph. Futhermore, we show that the complexity of our protection solution is low. We propose an implementation of this language as a dynamic mandatory access control for Linux. We experiment it on large scale high interaction honeypots. Our protection shows its efficiency both for clients and servers. Moreover, it presents interesting perspectives for the protection of other systems and for the vulnerability analysis. This work has contributed to the SPACLik project that wins the security contest of the French National Research Agency : ANR SEC&SI.
... In contrast to static analysis, dynamic detection monitors application execution to find software bugs without access to source code. These tools can be further classified into dynamic online analysis tools such as [27, 28] and post mortem analysis tools such as the one proposed by Ko et al. [29]. However, [29] can only detect the result of exploiting a TOCTTOU vulnerability and cannot locate the error. ...
TOCTTOU (Time-of-Check-To-Time-Of-Use) is a file-based race condition in Unix-style systems and characterized by a pair of file object access by a vulnerable program: a check operation establishes certain conditions about the file object (e.g., the file exists), followed by a use operation that assumes that the established condition still holds. Due to the lack of support for transactions in Unix-style file systems, an attacker can modify the established file condition in-between the check and use steps, thus causing significant harm. In this paper, we present a model of the TOCTTOU problem (called STEM), which enumerates all the potential file system call pairs (called exploitable TOCTTOU pairs) that form the check/use steps. The model shows that a successful TOCTTOU attack requires a change in the mapping of pathname to logical disk blocks between the check and use steps. We apply STEM to POSIX and Linux to demonstrate its practical value for Unix-style file systems. Then we propose a defense mechanism (called EDGI) that prevents an attacker from tampering with the file condition between exploitable TOCTTOU pairs during a vulnerable program’s execution. EDGI works at the file system level and does not require existing applications to change. We have implemented EDGI on Linux kernel 2.4.28 and our evaluation shows that EDGI is effective and incurs little overhead to application benchmarks such as Andrew and Postmark.
