Page History

Files on multiuser systems are generally owned by a particular user. The owner of the file can specify which other users on the system should be allowed to access the contents of these files.

These file systems use a privileges and permissions model to protect file access. When a file is created, the file access permissions dictate who may access or operate on the file. When a program creates a file with insufficiently restrictive access permissions, an attacker may read or modify the file before the program can modify the permissions. Consequently, files must be created with access permissions that prevent unauthorized file access.

Noncompliant Code Example

The constructors for FileOutputStream and FileWriter do not allow the programmer to explicitly specify file access permissions.

The C99 {{fopen()}} function is used to open an existing file or create a new one \[[ISO/IEC 9899:1999|AA. Bibliography#ISO/IEC 9899-1999]\]. However, {{fopen()}} does not indicate if an existing file has been opened for writing or a new file has been created. This may lead to a program overwriting or accessing an unintended file.

Noncompliant Code Example (FileOutputStream())

In this noncompliant code example, the file referenced by file is opened for writing. This example is noncompliant if the programmer's intent was to create a new file, but the referenced file already exists.access permissions of any file created are implementation-defined and may not prevent unauthorized access:

String file;
OutputStream Writer out = new FileOutputStreamFileWriter("file");

Compliant Solution (Java 1.

...

This compliant solution uses the CREATE_NEW option from Java 1.7, which causes an exception to be thrown if the file being created already exists.

Path file = new File("file").toPath();
try (OutputStream out = Files.newOutputStream( file, StandardOpenOption.CREATE_NEW);) {
  // write to out
};

Noncompliant Code Example (FileWriter())

In this noncompliant code example, the file referenced by file is opened for writing. Again, the example is noncompliant if the programmer's intent was to create a new file, but the referenced file already exists.

String file;
Writer out = new FileWriter(file);

Compliant Solution (Java 1.7, StandardOpenOption.CREATE_NEW)

6 and Earlier)

Java 1.6 and earlier lack a mechanism for specifying default permissions upon file creation. Consequently, the problem must be avoided or solved using some mechanism external to Java, such as by using native code and the Java Native Interface (JNI).

Compliant Solution (POSIX)

The  I/O facility java.nio provides classes for managing file access permissions. Additionally, many of the methods and constructors that create files accept an argument allowing the program to specify the initial file permissions.

The Files.newByteChannel() method allows a file to be created with specific permissions. This method is platform-independent, but the actual permissions are platform-specific. This compliant solution defines sufficiently restrictive permissions for POSIX platforms:This compliant solution uses the CREATE_NEW option from Java 1.7, which causes an exception to be thrown if the file being created already exists.

Path file = new File("file").toPath();
try (BufferedWriter out = Files.newBufferedWriter( file, Charset.forName("UTF8"),
                                     
// Throw exception rather than overwrite existing file
Set<OpenOption> options = new HashSet<OpenOption>();
options.add(StandardOpenOption.CREATE_NEW);
options.add(StandardOpenOption.APPEND);

// File permissions should be such that only user may read/write file
Set<PosixFilePermission> perms =
    PosixFilePermissions.fromString("rw-------");
FileAttribute<Set<PosixFilePermission>> attr =
    PosixFilePermissions.asFileAttribute(perms);

try (SeekableByteChannel sbc =
         Files.newByteChannel(file,     StandardOpenOption.CREATE_NEW);options, attr)) {
  // writeWrite to outdata
};

Risk Assessment

The ability to determine if an existing file has been opened or a new file has been created provides greater assurance that a file other than the intended file is not acted upon.

Automated Detection

TODO

Related Vulnerabilities

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

Related Guidelines

CERT C++ Secure Coding Standard: FIO03-CPP. Do not make assumptions about fopen() and file creation
CERT C Secure Coding Standard: FIO03-C. Do not make assumptions about fopen() and file creation

Bibliography

[[API 2006|AA. Bibliography#API 06]\] Class {{InputStream}}, {{DataInputStream}}
\[[J2SE 2011|AA. Bibliography#J2SE 11]\] The try-with-resources Statement
\[[Seacord 2005a|AA. Bibliography#Seacord 05]\] Chapter 7, "File I/O"

Exceptions

FIO01-J-EX0: When a file is created inside a directory that is both secure and unreadable by untrusted users, that file may be created with the default access permissions. This could be the case if, for example, the entire file system is trusted or is accessible only to trusted users (see FIO00-J. Do not operate on files in shared directories for the definition of a secure directory).

FIO01-J-EX1: Files that do not contain privileged information need not be created with specific access permissions.

Risk Assessment

If files are created without appropriate permissions, an attacker may read or write to the files, possibly resulting in compromised system integrity and information disclosure.

Automated Detection

Related Guidelines

Android Implementation Details

Creating files with weak permissions may allow malicious applications to access the files.

Bibliography

...

Image Added Image Added Image AddedFIO01-J. Do not expose buffers created using the wrap() or duplicate() methods to untrusted code      12. Input Output (FIO)      FIO05-J. Do not create multiple buffered wrappers on a single InputStream