Page History

...

Secure creation of temporary files is error prone and relies on platform dependent behavior, the Operating System and the file system being the determining factors. Code that works for a locally mounted file system, for example, may be vulnerable when used with a remotely mounted file system. Moreover, most relevant APIs are problematic. The only secure solution is to refrain from creating temporary files in shared directories.

Unique and Unpredictable filenames

A 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 as a result 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 noncompliant code example hardcodes the name of the temporary file which implies that the name is predictable. Even though there is a built-in check to detect whether a file still exists after its creation, a TOCTOU condition exists such that an attacker can alter or delete the file before it is read.

...

Additionally, the output stream has not been closed after use which violates FIO06-J. Ensure all resources are properly closed when they are no longer needed. Finally, the file is not deleted after use.

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. Files, or regions of files, can be locked to prevent two processes from concurrent access. The {{java.nio.channels.FileLock}} class facilitates file locking. According to the Java API \[[API 06|AA. Java References#API 06]\] documentation:

...

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 (even in the presence of a finally block that does not get a chance to execute), there is no surefire 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 appropriately.

Noncompliant Code Example

This noncompliant code example improves over the previous noncompliant code example by demonstrating how the method File.createTempFile() can be used to generate a unique temporary filename based on two parameters, a prefix and an extension. Currently, this is the only method that is designed for producing unique file names but even then, the names produced are not hard to predict. It is recommended that the prefix be generated using a good random number generator.

...

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 is not closed first, file will not be deleted
      f.deleteOnExit(); // Delete the file when the JVM terminates
    }
  }       
}

Compliant Solution

As a workaround to the file/stream termination issue described above, always try to terminate the resource first. This should have been done using {{fop.close()}} in the noncompliant code 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. It is highly recommended that temporary files be created only in secure directories.

Risk Assessment

Not 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

GERONIMO-3489

Other Languages

This rule appears in the C Secure Coding Standard as FIO43-C. Do not create temporary files in shared directories.

This rule appears in the C++ Secure Coding Standard as FIO43-CPP. Do not create temporary files in shared directories.

References

\[[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"

...