Page History

...

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 MarkupPrivileged 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.

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:

...

* If the program terminates abnormally, this behavior is implementation-defined.

* If the program terminates abnormally, this behavior is implementation-defined.

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 None of these functions are without problems. The best advice is not to create temporary files in shared directories (see FIO15-A. Do not 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.

Unique and Unpredictable file namesnames

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 05|AA. C References#Seacord 05]\] Chapter 7).

Files, or regions of files, can be locked to prevent two processes from concurrent access. Windows supports file locking of two types: shared locks two types of file locks:

• shared locks, provided by LockFile(), prohibit all write access to the locked file region while allowing concurrent read access to all processes

...

• .
• exclusive locks, provided by LockFileEx(), grant unrestricted file access to the locking process while denying access to all other processes.

In both cases A call to LockFile() obtains shared access; exclusive access is accomplished via LockFileEx(). In either case the lock is removed by calling UnlockFile().

...

These Windows file-locking mechanisms are called mandatory locks because every process attempting access to a locked file region is subject to the restriction. Linux implements both mandatory locks and advisory locks. An advisory lock is not enforced by the operating system, which severely diminishes its value from a security perspective. Unfortunately, the mandatory file lock in Linux is also largely impractical for the following reasons:

1. mandatory locking works only on local file systems and does not extend to network file systems (such as NFS and 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

It is important to remember to cleanup in order to allow filenames 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 tmp temp cleaner utilities which are widely used. These tmp cleaners are invoked manually by a system administrator or periodically run as by a cron daemon to sweep temporary directories and remove old files . These tmp cleaners are widely used. However, these utilities are themselves vulnerable to file-based exploits, and often require the use of shared directories (see FIO15-A. Do not create temporary files in shared directories). However, during normal operation, it is the responsibility of the program to ensure that temporary files are removed either removed explicitly, or through the use of library routines such as tmpfile_s which guarantee their removal temporary file deletion upon program termination.

...