Difference between revisions of "File Access Race Condition: TOCTOU"

From OWASP
Jump to: navigation, search
 
(4 intermediate revisions by one user not shown)
Line 1: Line 1:
 +
{{Template:Stub}}
 
{{Template:Vulnerability}}
 
{{Template:Vulnerability}}
 
{{Template:Fortify}}
 
{{Template:Fortify}}
{{Template:Stub}}
 
 
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
 
  
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
 
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 
[[ASDR Table of Contents]]
 
__TOC__
 
 
  
 
==Description==
 
==Description==
Line 76: Line 70:
 
TBD
 
TBD
  
[[Category:FIXME|add links
 
 
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
 
 
Availability Vulnerability
 
 
Authorization Vulnerability
 
 
Authentication Vulnerability
 
 
Concurrency Vulnerability
 
 
Configuration Vulnerability
 
 
Cryptographic Vulnerability
 
 
Encoding Vulnerability
 
 
Error Handling Vulnerability
 
 
Input Validation Vulnerability
 
 
Logging and Auditing Vulnerability
 
 
Session Management Vulnerability]]
 
  
 
__NOTOC__
 
__NOTOC__
Line 107: Line 76:
 
[[Category:OWASP ASDR Project]]
 
[[Category:OWASP ASDR Project]]
 
[[Category:Synchronization and Timing Vulnerability]]
 
[[Category:Synchronization and Timing Vulnerability]]
[[Category:Access Control Vulnerability]]
+
[[Category:Authorization Vulnerability]]
 
[[Category:C]]
 
[[Category:C]]
 
[[Category:Implementation]]
 
[[Category:Implementation]]
 
[[Category:Code Snippet]]
 
[[Category:Code Snippet]]
 
[[Category:File System]]
 
[[Category:File System]]
 +
[[Category:Vulnerability]]

Latest revision as of 20:11, 20 February 2009

This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.


This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.


This article includes content generously donated to OWASP by Fortify.JPG.

Last revision (mm/dd/yy): 02/20/2009

Vulnerabilities Table of Contents

Description

The window of time between when a file property is checked and when the file is used can be exploited to launch a privilege escalation attack.

File access race conditions, known as time-of-check, time-of-use (TOCTOU) race conditions, occur when:

  • The program checks a property of a file, referencing the file by name.
  • The program later performs a filesystem operation using the same filename and assumes that the previously-checked property still holds.


Risk Factors

TBD

Examples

The following code is from a program installed setuid root. The program performs certain file operations on behalf of non-privileged users, and uses access checks to ensure that it does not use its root privileges to perform operations that should otherwise be unavailable the current user. The program uses the access() system call to check if the person running the program has permission to access the specified file before it opens the file and performs the necessary operations.

	if(!access(file,W_OK)) {
		f = fopen(file,"w+");
	        operate(f);
		...
	}
	else {
	fprintf(stderr,"Unable to open file %s.\n",file);
	}

The call to access() behaves as expected, and returns 0 if the user running the program has the necessary permissions to write to the file, and -1 otherwise. However, because both access() and fopen() operate on filenames rather than on file handles, there is no guarantee that the file variable still refers to the same file on disk when it is passed to fopen() that it did when it was passed to access(). If an attacker replaces file after the call to access() with a symbolic link to a different file, the program will use its root privileges to operate on the file even if it is a file that the attacker would otherwise be unable to modify. By tricking the program into performing an operation that would otherwise be impermissible, the attacker has gained elevated privileges.

This type of vulnerability is not limited to programs with root privileges. If the application is capable of performing any operation that the attacker would not otherwise be allowed perform, then it is a possible target.

The window of vulnerability for such an attack is the period of time between when the property is tested and when the file is used. Even if the use immediately follows the check, modern operating systems offer no guarantee about the amount of code that will be executed before the process yields the CPU. Attackers have a variety of techniques for expanding the length of the window of opportunity in order to make exploits easier, but even with a small window, an exploit attempt can simply be repeated over and over until it is successful.


Related Attacks


Related Vulnerabilities


Related Controls


Related Technical Impacts


References

TBD