Information AboutTime-of-check-to-time-of-use |
| CATEGORIES ABOUT TIME-OF-CHECK-TO-TIME-OF-USE | |
| security exploits | |
|
A simple example is as follows: Consider a Web application that allows a user to edit pages, but allows administrators to lock pages to prevent editing. A user requests to edit a page, getting a form by which they 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 they submit the form, their edits are accepted. When the user began editing, their authorization was ''checked'', and they were indeed allowed to edit. However, the authorization was ''used'' later, after they should no longer have been allowed. ''ACCESS'' EXAMPLE In Unix , the following C code, when used in a Setuid program, is a TOCTTOU bug: if (access(file, R_OK) != 0) { exit(1); } fd = open(file, O_RDONLY); // do something with fd... Here, ''access'' is intended to check whether the real user who executed the setuid program would normally be allowed to read the file (i.e., ''access'' checks the Real Userid rather than Effective Userid ). This race condition is vulnerable to an attack: # Create a file the user can read # Start the program # Change the file to a Symlink pointing to a file that the user shouldn't be able to read Although this sequence of events requires precise timing, it is possible for an attacker to arrange such conditions without too much difficulty. The implication is that the ''access'' system call, as it currently exists in Unix, should never be used. REFERENCES |
|
|