Page History

Temporary files are frequently created in shared directories and have several uses:can be used to

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

An adversary can cause a program to incorrectly interpret the temporary data if temporary files are not created safely or beget a denial of service if the file is not deleted after use. For instance, if the name of the file can be predetermined, an attacker can use the time-of-check-to-time-of-use (TOCTOU) condition to create a file with the same name leading to either a failure in creating the temporary file from within program code or the program reading a crafted file determined by the attacker.

• .

Temporary files are files and consequently must conform to the requirements specified by other rules governing operations on files, including FIO00-J. Do not operate on files in shared directories and FIO01-J. Create files with appropriate access permissions. Temporary files have the additional requirement that they must be removed before program termination.

Removing temporary files when they are no longer required allows file names and other resources (such as secondary storage) to be recycled. Each program is responsible for ensuring that temporary files are removed during normal operation. There is no surefire method that can guarantee the removal of orphaned files in the case of abnormal termination, even in the presence of a finally block, because the finally block may fail to execute. For this reason, many systems employ temporary file cleaner utilities to sweep temporary directories and remove old files. Such utilities can be invoked manually by a system administrator or can be periodically invoked by a system process. However, these utilities are themselves frequently vulnerable to file-based exploits Wiki MarkupA recently identified bug manifests in JRE and JDK version 6.0 and prior, wherein an attacker can predict the names of the temporary files and thus write malicious JAR files via unknown vectors \[[CVE 08|AA. Java References#CVE 08]\]. Denial of Service attacks are also possible if unclaimed temporary resources cause rapid disk space exhaustion \[[Secunia Advisory 20132|http://secunia.com/advisories/20132/]\].

Noncompliant Code Example

This and subsequent code examples assume that files are created in a secure directory in compliance with FIO00-J. Do not operate on files in shared directories and are created with proper access permissions in compliance with FIO01-J. Create files with appropriate access permissions. Both requirements may be managed outside the Java Virtual Machine (JVM).

This noncompliant code example fails to remove the file upon completion: noncompliant code example suffers from several pitfalls. First, the name of the temporary file is hardcoded which implies that it is predictable. Second, even though there is a built-in check to detect whether a file still exists after creation, a TOCTOU condition exists that can prevent a program from making use of the temporary file. Third, the output stream has not been closed after use which violates FIO34-J. Ensure all resources are properly closed when they are no longer needed. Finally, no measure to delete the file after use has been considered.

class TempFile {
  public static void main(String[] args) throws IOException{
    File f = new File("tempnam.tmp");
    if (f.exists()) {
      System.out.println("This file already exists");
      return;
    }

    FileOutputStream fop = null;
    try {
      fop = new FileOutputStream(f);
      String str = "Data";
      fop.write(str.getBytes());
    } finally {
      if(f.exists()){
 (fop != null) {
        try {
          fop.writeclose(str.getBytes());
        } elsecatch (IOException x) { System.out.println("This file does not exist");
          // Handle error
        }
      }
    }
  }
}

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

This noncompliant code example improves by demonstrating how invokes the method File.createTempFile can be used to generate () method, which generates a unique temporary filename file name based on two parameters, : a prefix and an extension. Currently, this This is the only method from Java 6 and earlier that is designed for producing to produce unique file names but quite unfortunately, although the names produced are not hard to predict. It is recommended that the prefix be generated using a good random number generator.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 uses the deleteOnExit() method to ensure that the temporary file is deleted when the JVM terminates. However, according to the Java API [API 2014] Class File, method deleteOnExit() documentation, Wiki MarkupAccording to \[[API 06|AA. Java References#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 therefore be used with care.
Note: this method should not be used for file-locking, as the resulting protocol cannot be made to work reliably.

Wiki MarkupThis implies that the file would not be deleted if the JVM terminates unexpectedly. Another longstanding bug that remains unresolved violates the temporary file deletion contract provided by the {{deleteOnExit}} method. If a stream or a {{RandomAccessFile}} is left unclosed before calling {{deleteOnExit}}, the file would not be deleted on Win32 based systems \[[Bug ID: 4171239|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4171239]\]. Consequently, the file is not deleted if the JVM terminates unexpectedly. A longstanding bug on Windows-based systems, reported as Bug ID: 4171239 [SDN 2008], 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 = null;
    try {
      fop = new FileOutputStream(f);
      String str = "Data";
    try {
      fop.write(str.getBytes());
      fop.flush();        
    } finally {
      // Stream/file still open; file will
 closing not performed first, file will// not be deleted on Windows systems
      f.deleteOnExit(); // Delete the file when the JVM terminates

      if (fop != null) {
        try {
          fop.close();
        } catch (IOException x) {
          // Handle error
        }
      }
    }
  }
}

Compliant Solution

...

<TODO> depending on bug fixes. As a workaround to the file/stream termination issue, always try to terminate the resource first. This should have been done using {{fop.close();}} in the above noncompliant example. It is also recommended that {{File.io.delete}} be used to immediately delete the file to avoid improper JVM termination related issues. Moreover, although unreliable, {{System.gc()}} may be invoked to free up related resources. Sometimes, it is not possible to close the resources on which the delete operation has to be invoked \[[Bug ID: 4635827|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4635827]\]. Currently, there is no way to handle this case.

Risk Assessment

(DELETE_ON_CLOSE)

This compliant solution creates a temporary file using several methods from Java's NIO.2 package (introduced in Java SE 7). It uses the createTempFile() method, which creates an unpredictable name. (The actual method by which the name is created is implementation-defined and undocumented.) The file is opened using the try-with-resources construct, which automatically closes the file regardless of whether an exception occurs. Finally, the file is opened with the DELETE_ON_CLOSE option, which removes the file automatically when it is closed.

class TempFile {
  public static void main(String[] args) {
    Path tempFile = null;
    try {
      tempFile = Files.createTempFile("tempnam", ".tmp");
      try (BufferedWriter writer =
          Files.newBufferedWriter(tempFile, Charset.forName("UTF8"),
                                  StandardOpenOption.DELETE_ON_CLOSE)) {
        // Write to file
      }
      System.out.println("Temporary file write done, file erased");
    } catch (FileAlreadyExistsException x) {
      System.err.println("File exists: " + tempFile);
    } catch (IOException x) {
      // Some other sort of failure, such as permissions.
      System.err.println("Error creating temporary file: " + x);
    }
  }
}

Compliant Solution

When a secure directory for storing temporary files is not available, the vulnerabilities that result from using temporary files in insecure directories can be avoided by using alternative 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).

Risk Assessment

Failure to remove temporary files before termination can result in information leakage and resource exhaustionNot following the best practices while creating, using and deleting temporary files can lead to denial of service vulnerabilities, misinterpretations and alterations in control flow.

Automated Detection

TODO

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Other Languages

...

Related Guidelines

...

...

...

...

...

...

...

\[[API 06|AA. Java References#API 06]\] Class File, methods {{createTempFile}}, {{delete}}, {{deleteOnExit}}
\[[Darwin 04|AA. Java References#Darwin 04]\] 11.5 Creating a Transient File
\[[SDN 08|AA. Java References#SDN 08]\] Bug IDs: 4171239, 4405521, 4635827, 4631820
\[[Secunia 08|AA. Java References#Secunia 08]\] [Secunia Advisory 20132|http://secunia.com/advisories/20132/]
\[[CVE 08|AA. Java References#CVE 08]\] [CVE-2008-5354|http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5354]
\[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 459 |http://cwe.mitre.org/data/definitions/459.html] "Incomplete Cleanup", [CWE ID 377|http://cwe.mitre.org/data/definitions/377.html] "Insecure Temporary File"

Bibliography

...

Image Added Image Added Image AddedMSC31-J. Never hardcode sensitive information      08. Input Output (FIO)      08. Input Output (FIO)