Page History

...

• Share data between processes
• Store auxiliary program data (for example, to preserve memory)
• Construct and/or load classes, JAR files, and native libraries dynamically

Programmers frequently create temporary files in directories that are writable by everyone; examples include /tmp and /var/tmp on UNIX and C:\TEMP on Windows. Files in such directories may be purged regularly, for example, such as every night or during reboot. However, an attacker who has access to the local file system can exploit operations on files in shared directories when those files are created insecurely or remain accessible after use. For example, an attacker who can both predict the name of a temporary file and can change or replace that file , can exploit a time-of-check time-of-use (TOCTOU) condition to cause either a failure in creating the temporary file from within program code or operating on a file determined by the attacker. This exploit is particularly dangerous when the vulnerable program is running with elevated privileges. On multiuser systems, a user can be tricked by an attacker into unintentionally operating on their own files. Consequently, temporary file management must comply with FIO00-J. Do not operate on files in shared directories.

Many programs that create temporary files attempt to give them unique and unpredictable file names. This is a common attempt at mitigating the risk of creating a file in an insecure or shared directory. If the filename file name is not sufficiently unique or random, an attacker can guess or predict the name of the file to be created , and create a file link with the same name, the final target of which is a file selected by the attacker. However, if a temporary file is created in a secure directory, an attacker cannot tamper with the file, and so the need for unpredictable names is eliminated.

Temporary files are files and consequently must conform to the requirements specified by other rules governing operations on files, including void FIO00-J. Do not overwrite an existing file while attempting to create a new file, and FIO01-J. Create files with appropriate access permissions. Furthermore, temporary files have an additional requirement in that they must be removed before program termination.

...

For this and subsequent code examples, we will assume that the files are automatically being created in a secure directory, to comply with rule FIO00-J. Do not operate on files in shared directories. We will also assume the files are created with proper access permissions, to compy with FIO01-J. Create files with appropriate access permissions. Both requirements may be managed outside the JVM.

...

class TempFile {
  public static void main(String[] args) throws IOException{
    File f = new File("tempnam.tmp");
    FileOutputStream fop = new FileOutputStream(f);
    String str = "Data";
    
    if (f.exists()) {
      fop.write(str.getBytes());
      fop.close();
    } else { 
      System.out.println("This file does not exist"); 
    }
  }      
}

Noncompliant Code Example (createTempFile(), deleteOnExit())

This noncompliant code example invokes the File.createTempFile() method, which generates a unique temporary filename file name based on two parameters, a prefix and an extension. This is the only method currently designed and provided for producing unique file names; , although the names produced can be easily predicted. A random number generator can be used to produce the prefix if a random file name is required.

This example also attempts to use the {{deleteOnExit()}} method to ensure that the temporary file is deleted when the JVM terminates. However, according to the Java API \[[API 2006|AA. Bibliography#API 06]\] Class {{File}}, method {{deleteOnExit()}} documentation:,

Deletion will be attempted only for normal termination of the virtual machine, as defined by the Java Language Specification. Once deletion has been requested, it is not possible to cancel the request. This method should consequently be used with care.
Note: this method should not be used for file-locking, as the resulting protocol cannot be made to work reliably.

Consequently, the file is not deleted if the JVM terminates unexpectedly. A longstanding bug on Windows based systems reported as [Bug ID: 4171239|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4171239] \[[SDN 2008|AA. Bibliography#SDN 08]\] causes JVMs to fail to delete a file when {{deleteOnExit()}} is invoked before the associated stream or {{RandomAccessFile}} is closed. 

class TempFile {
  public static void main(String[] args) throws IOException{
    File f = File.createTempFile("tempnam",".tmp");
    FileOutputStream fop = new FileOutputStream(f);
    String str = "Data";
    try {
      fop.write(str.getBytes());
      fop.flush();        
    } finally {
      // Stream/file still open; file will
      // not be deleted on Windows systems
      f.deleteOnExit(); // Delete the file when the JVM terminates
    }
  }       
}

Compliant Solution (Java 1.7), DELETE_ON_CLOSE)

...

If a secure directory for storing temporary files is not available, then the vulnerabilities that result from using temporary files in insecure directories can be avoided by using alternate mechanisms, including:

• other IPC mechanisms such as sockets and remote procedure calls
• the low-level Java Native Interface (JNI).
• memory mapped files
• threads to share heap data within the same JVM (applies to data sharing between Java processes only)
• a secure directory that can be accessed only by application instances, provided that multiple instances of the application running on the same platform avoid competing for the same files.

Risk Assessment

Failure to follow best practices while creating, using, and deleting temporary files can lead to information leakage, misinterpretations, and alterations in control flow.

...

Bibliography

...