Page History

...

This is a dangerous practice, because a well-known file in a shared directory can be easily hijacked or manipulated by an attacker. Mitigation strategies include the following:1.

1. Use other low-level IPC mechanisms such as sockets or shared memory.

...

1. Use higher level IPC mechanisms such as remote procedure calls.

...

1. Use a secure directory or a jail that can only be accessed by application instances (making sure that multiple instances of the application running on the same platform do not compete).

There are many different interprocess communication (IPC) mechanisms, some of which require the use of temporary files, while others do not. An example of an IPC mechanism that uses temporary files is the POSIX mmap() function. Berkley Berkeley Sockets, POSIX Local IPC Sockets, and System V Shared Memory do not require temporary files. Because the multiuser nature of shared directories poses an inherent security risk, the use of shared temporary files for IPC is discouraged.

...

Securely creating temporary files 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. Moreover, none of these functions are without problems. The only secure solution is not to create temporary files in shared directories.

Unique and Unpredictable File Names

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|AA. C References#HP 03]\]. Unprivileged programs can be similarly exploited to overwrite protected user files.

Exclusive Access

Exclusive access grants unrestricted file access to the locking process while denying access to all other processes and eliminates the potential for a race condition on the locked region (see \[[Seacord 05a|AA. C References#Seacord 05]\] Chapter 7).

...

1. Mandatory locking works only on local file systems and does not extend to network file systems (such as NFS or AFS)
2. File systems must be mounted with support for mandatory locking, and this is disabled by default
3. Locking relies on the group ID bit that can be turned off by another process (thereby defeating the lock)

Removal Before Termination

Removing temporary files when they are no longer required allows file names and other resources (such as secondary storage) to be recycled. In the case of abnormal termination, there is no sure method that can guarantee the removal of orphaned files. For this reason, temporary file cleaner utilities, which are invoked manually by a system administrator or periodically run by a daemon to sweep temporary directories and remove old files, are widely used. However, these utilities are themselves vulnerable to file-based exploits and often require the use of shared directories. During normal operation, it is the responsibility of the program to ensure that temporary files are removed either explicitly or through the use of library routines such as tmpfile_s which guarantee temporary file deletion upon program termination.

...

A call to mkstemp() replaces the six X's in the template string with six randomly selected characters and returns a file descriptor for the file (opened for reading and writing), as in this compliant solution.

...

This solution is not serially reusable, however, because the mkstemp() function replaces the "XXXXXX" in template the first time it is invoked. This is not a problem as long as template is reinitialized before calling mkstemp() again. If template is not reinitialized, the mkstemp() function will return -1 and leave template unmodified because template did not contain six X's.

The Open Group Base Specification Issue 6 \[[Open Group 04|AA. C References#Open Group 04]\] does not specify the permissions the file is created with, so these are [implementation-defined|BB. Definitions#implementation-defined behavior]. However, Issue 7 (POSIX.1-2008) specifies them as {{S_IRUSR\|S_IWUSR}} (0600) \[[Austin Group 08|AA. C References#Austin Group 08]\].

This compliant solution invokes an implementation-specific the user-defined function secure_dir()} function (such as the one defined in FIO15-C. Ensure that file operations are performed in a secure directory) to ensure the temporary file resides in a secure directory.

...

In many older [implementations|BB. Definitions#implementation], the name is a function of process ID and time, so it is possible for the attacker to predict the name and create a decoy in advance.  FreeBSD changed the {{mk*temp()}} family to eliminate the PID component of the file name and replace the entire field with base-62 encoded randomness.  This raises the number of possible temporary files for the typical use of six {{X}}'s significantly, meaning that even {{mktemp()}} with six {{X}}'s is reasonably (probabilistically) secure against guessing, except under frequent usage \[[Kennaway 00|AA. C References#Kennaway 00]\].

...