You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 59 Next »

Temporary files can be used to

  • Share data between processes
  • Store auxiliary program data (for example, to save 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, every night or during reboot. However, an attacker who has access to the local file system can misuse files held in world-writable 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 FIO04-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 is not sufficiently unique or random, an attacker can guess or predict the name of the file to be created, and create a symbolic 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 FIO00-J. Do not overwrite an existing file while attempting to create a new file, and FIO03-J. Create files with appropriate access permissions. Furthermore, temporary files have an 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 daemon. However, these utilities are themselves vulnerable to file-based exploits and may require the use of secure directories.

We will assume that the code samples shown below obey all these rules: That is, the files are created in the current directory of the program, which is assumed to be a secure directory. Also, the files are created with appropriate access permissions, which are managed by default outside Java. The code samples below make sure that no existing file is overwritten.

Noncompliant Code Example

This noncompliant code example hardcodes the name of a temporary file; consequently, the file's name is predictable. However, the program makes no attempt to remove the file upon completion.

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"); 
    }
  }      
}


h2. Noncompliant Code Example ({{createTempFile()}}, {{deleteOnExit()}})

This noncompliant code example invokes the {{File.createTempFile()}} method which generates a unique temporary filename 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. If the filename must be unpredictable, this problem can be solved by using a good random number generator to produce the prefix.

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:
{quote}
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.
{quote}

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. 

{code:bgColor=#FFcccc}
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)

This compliant solution creates a temporary file using several methods of Java 1.7's NIO package. It uses the createTempFile() method, which creates an unpredictable name. (The actual method by which the name is created is implementation-defined and undocumented.) Additionally, the createTempFile() will throw an exception if the file already exists. The file is opened using the try-with-resources construct, which automatically closes the file whether or not an exception occurs. Finally, the file is opened with the Java 1.7 DELETE_ON_CLOSE option, which serves to remove 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);
    }
  }
}

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.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

FIO07-J

high

probable

medium

P12

L1

Related Guidelines

Bibliography

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="fe866752-1732-4d47-810f-27be2e692c97"><ac:plain-text-body><![CDATA[

[[API 2006

AA. Bibliography#API 06]]

Class File, methods createTempFile, delete, deleteOnExit

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="1a27169a-f183-4042-9284-f81408116a05"><ac:plain-text-body><![CDATA[

[[CVE 2008

AA. Bibliography#CVE 08]]

[CVE-2008-5354

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5354]

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="a707b424-a221-42bf-9040-1d638741a922"><ac:plain-text-body><![CDATA[

[[Darwin 2004

AA. Bibliography#Darwin 04]]

11.5 Creating a Transient File

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="3162aa57-9104-43a1-adbc-21c095ac52f3"><ac:plain-text-body><![CDATA[

[[J2SE 2011

AA. Bibliography#J2SE 11]]

 

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="ced2199f-f8de-4bbe-9252-83e4ec56e028"><ac:plain-text-body><![CDATA[

[[SDN 2008

AA. Bibliography#SDN 08]]

Bug IDs: 4171239, 4405521, 4635827, 4631820

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="ae29454f-b100-4f2c-b7c8-d0c68f9ea802"><ac:plain-text-body><![CDATA[

[[Secunia 2008

AA. Bibliography#Secunia 08]]

[Secunia Advisory 20132

http://secunia.com/advisories/20132/]

]]></ac:plain-text-body></ac:structured-macro>


FIO06-J. Close resources when they are no longer needed      12. Input Output (FIO)      FIO08-J. Do not log sensitive information outside a trust boundary

  • No labels