Time-of-check to time-of-use: Difference between revisions

Content deleted Content added
tidy a bit
Line 1:
AIn [[software development]], '''time-of-check-to-time-of-use bug''' ('''TOCTTOU''', pronounced "''TOCK too''") is a class of [[software bug]] caused by changes in a system between the ''checking'' of a condition (such as a security credential) and the ''use'' of the results of that check. It is a kind of [[race condition]].
 
A simple example is as follows: Consider a Web application that allows a user to edit pages, and also allows administrators to lock pages to prevent editing. A user requests to edit a page, getting a form by which he can alter its content. Before the user submits the form, an administrator locks the page, which should prevent editing. However, since the user has already begun editing, when he submits the form, his edits are accepted. When the user began editing, his authorization was ''checked'', and he was indeed allowed to edit. However, the authorization was ''used'' later, after he should no longer have been allowed.
 
TOCTTOU race conditions are most common in UNIX file systems, specifically[[Unix]] between operations on the [[File system#Metadata|file system]], but can occur in other contexts, including local sockets and improper use of [[database transaction]]s. Early versions of OpenSSH had an exploitable race condition for UNIXUnix ___domain sockets.<ref>Acheson, Steve; [http://www.employees.org/~satch/ssh/faq/TheWholeSSHFAQ.html Acheson, Steve; SSH FAQ].</ref>
 
== ''access'' ExampleExamples ==
 
In [[Unix]], the following [[C (programming language)|C]] code, when used in a <code>[[setuid]]</code> program, is a TOCTTOU bug:
Line 16:
write(fd, buffer, sizeof(buffer));
</source>
 
Here, ''access'' is intended to check whether the real user who executed the <code>setuid</code> program would normally be allowed to write the file (i.e., <code>''access''</code> checks the [[real userid]] rather than [[effective userid]]).
 
Line 55 ⟶ 56:
Exploiting a TOCTTOU race condition requires precise timing to ensure that the attacker's operations interleave properly with the victim's. In the example above, the attacker must execute the <code>symlink</code> system calls precisely between the <code>access</code> and <code>open</code>. For the most general attack, the attacker must be scheduled for execution after each operation by the victim, also known as "single-stepping" the victim.
 
Techniques for single-stepping a victim program include file system mazes<ref>[http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.117.7757 Borisov, Nikita; Johnson, Rob; Sastry, Naveen; and Wagner, David; 2005; [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.117.7757 ''Fixing Races for Fun and Profit: How to abuse atime'']; Proceedings of the 14th Conference on USENIX Security Symposium<!-- sic! --> (Security'05), Baltimore (MD), July 31–August 5, 2005, Vol. 14, pp. 303–314]</ref> and algorithmic complexity attacks.<ref>[http://www.cs.sunysb.edu/~rob/papers/races2.pdf Cai, Xiang; Gui, Yuwei; and Johnson, Rob; 2009; [http://www.cs.sunysb.edu/~rob/papers/races2.pdf ''Exploiting UNIX file-system races via algorithmic complexity attacks'']; Proceedings of the IEEE Symposium on Security and Privacy, Berkeley (CA), May 17–20, 2009.]</ref> In both cases, the attacker manipulates the OS state to control scheduling of the victim.
 
File system mazes force the victim to read a directory entry that is not in the OS cache, and the OS puts the victim to sleep while it is reading the directory from disk. Algorithmic complexity attacks force the victim to spend its entire scheduling quantum inside a single system call traversing the kernel's hash table of cached file names. The attacker creates a very large number of files with names that hash to the same value as the file the victim will look up.
Line 61 ⟶ 62:
== Preventing TOCTTOU ==
 
Despite conceptual simplicity, TOCTTOU race conditions are difficult to avoid and eliminate. In the context of file system TOCTTOU race conditions, the fundamental challenge is ensuring that the file system cannot be changed between two system calls. In 2004, an impossibility result was published, showing that there was no portable, deterministic technique for avoiding TOCTTOU race conditions.<ref>Dean, Drew; and Hu, Alan J.; 2004; [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.83.8647 Dean, Drew; and Hu, Alan J.; 2004; ''Fixing races for fun and profit: How to use access(2)'']; Proceedings of the 13th USENIX Security Symposium, San Diego (CA), August 9–13, 2004, pp. 195–206]</ref>
 
Since this impossibility result, most UNIX systems (including Linux and Solaris) have adopted variants of common file system calls that operate on file handles rather than file names. These calls end in the "at" suffix, such as <code>openat</code>, <code>statat</code>, etc. Because file handles are a private mapping to a file, they cannot be changed by another program and are not subject to race conditions with other applications. The example above can be rewritten using these calls to avoid a TOCTTOU race condition:
Line 75 ⟶ 76:
</source>
 
This example is safe from race conditions because the file name "file" is only looked up once. More elaborate libraries for tracking file descriptors and ensuring correctness have been proposed by researchers.<ref>[http://domino.watson.ibm.com/library/CyberDig.nsf/1e4115aea78b6e7c85256b360066f0d4/c4028924309762d18525746e004a4feb Tsafrir, Dan; Hertz, Tomer; Wagner, David; and Da Silva, Dilma; 2008; [http://domino.watson.ibm.com/library/CyberDig.nsf/1e4115aea78b6e7c85256b360066f0d4/c4028924309762d18525746e004a4feb "Portably preventing file race attacks with user-mode path resolution"]; Technical Report RC24572, IBM T. J. Watson Research Center; June 2008, Yorktown Heights (NY)]</ref>
 
An alternative solution proposed in the research community is for UNIX systems to adopt transactions in the file system or the OS kernel. Transactions provide a [[concurrency control]] abstraction for the OS, and can be used to prevent TOCTTOU races. While no production UNIX kernel has yet adopted transactions, proof-of-concept research prototypes have been developed for Linux, including the Valor file system<ref>[http://www.fsl.cs.sunysb.edu/docs/valor/valor_fast2009.pdf Spillane, Richard; Gaikwad, Sachin; Chinni, Manjunath; Zadok, Erez; and Wright, Charles P.; 2009; [http://www.fsl.cs.sunysb.edu/docs/valor/valor_fast2009.pdf "Enabling transactional file access via lightweight kernel extensions"]; Seventh USENIX Conference on File and Storage Technologies (FAST 2009), San Francisco (CA), February 24–27, 2009]</ref> and the TxOS kernel.<ref>[http://www.sigops.org/sosp/sosp09/papers/porter-sosp09.pdf Porter, Donald E.; Hofmann, Owen S.; Rossbach, Christopher J.; Benn, Alexander; and Witchel, Emmett; 2009; [http://www.sigops.org/sosp/sosp09/papers/porter-sosp09.pdf "Operating System Transactions"]; In Proceedings of the 22nd ACM Symposium on Operating Systems Principles (SOSP '09), Big Sky (MT), October 11–14, 2009.]</ref> [[Microsoft Windows]] has added transactions to its [[NTFS]] file system.<ref>Russinovich, Mark; and Solomon, David A.; 2009; Windows Internals; Microsoft Press</ref>
 
[[File locking]] is a common technique for preventing race conditions for a single file, but it does not extend to the file system namespace and other metadata, and cannot prevent TOCTTOU race conditions.
 
== References ==
 
{{Reflist}}
 
== Further reading ==
 
* Bishop, Matt; and Dilger, Michael; 1996; [http://nob.cs.ucdavis.edu/bishop/papers/1996-compsys/racecond.pdf ''Checking for race conditions in file accesses'']; Computing Systems, Vol. 9, No. 2, pp. 131–152
* Tsafrir, Dan; Hertz, Tomer; Wagner, David; and Da Silva, Dilma; 2008; [http://www.cs.berkeley.edu/~daw/papers/tocttou-fast08.pdf ''Portably Solving File TOCTTOU Races with Hardness Amplification''], Proceedings of the 6th USENIX Conference on File and Storage Technologies (FAST '08), San Jose (CA), February 26–29, 2008, pp. 189–206