Programmers frequently create temporary files. Commonly, temporary file directories are writable by everyone (examples being /tmp and /var/tmp on UNIX, and C:\TEMP on Windows) and may be purged regularly (for example, every night or during reboot).
When two or more users, or a group of users, have write permission to a directory, the potential for sharing and deception is far greater than it is for shared access to a few files. The vulnerabilities that result from malicious restructuring via hard and symbolic links suggest that it is best to avoid shared directories.
Securely creating temporary files in a shared directory is error prone and dependent on the version of the C runtime library used, the operating system, and the file system. Code that works for a locally mounted file system, for example, may be vulnerable when used with a remotely mounted file system.
| Wiki Markup |
|---|
Privileged programs that create temporary files in world-writable directories can be exploited to overwrite protected system files. An attacker who can predict the name of a file created by a privileged program can create a symbolic link (with the same name as the file used by the program) to point to a protected system file. Unless the privileged program is coded securely, the program will follow the symbolic link instead of opening or creating the file that it is supposed to be using. As a result, a protected system file to which the symbolic link points can be overwritten when the program is executed \[HP 03\]. Unprivileged programs can be similarly exploited to overwrite protected user files. |
Consequently, certain rules need to be followed when using temporary files to mitigate or lessen the dangers associated with using them.
At a minimum, the following requirements must be met when creating temporary files:
- Temporary files must be created with unique and unpredictable file names
- Temporary files must be opened with exclusive access
- Temporary files must removed before the program exits
- The file must be opened with appropriate permissions.
The following table lists common temporary file functions and their respective conformance to the above criteria:
| | | | | | |
|---|---|---|---|---|---|---|
Unpredictable name | Not portably | Yes | Not portably | Yes | Not portably | Not portably |
Unique Name | Yes | Yes | Yes | Yes | Yes | Yes |
Atomic | No | No | Yes | Yes | No | Yes |
Exclusive Access | Possible | Possible | No | If supported by OS | Possible | If supported by OS |
Appropriate Permissions | Possible | Possible | No | If supported by OS | Possible | Not portably |
File Removed | No | No | Yes* | Yes* | No | No |
* If the program terminates abnormally, this behavior is implementation-defined.
None of these functions are without problems. The best advice is not to create temporary files in shared directories. In cases where it is absolutely necessary to do so, however, the tmpfile_s() and mkstemp() provide the most secure solutions.
When working with temporary files inside of shared directories, it is important to simultaneously address 3 issues
...
Unique and Unpredictable file names
...