Page History

...

During this time the canonical path name may have been modified and may no longer be referencing a valid file. The canonical path name can be used to determine if the referenced file name is in a secure directory (see FIO00-J. Do not operate on files in shared directories). If the referenced file is in a secure directory, then by definition, an attacker cannot tamper with it, and cannot exploit the race condition.

This rule is a specific instance of IDS01-J. Normalize strings before validating them.

...

This noncompliant code example accepts a file path as a command line argument and uses the File.getAbsolutePath() method to obtain the absolute file path. This method It also uses the isInSecureDir() method defined in FIO00-J. Do not operate on files in shared directories to ensure that the file is in a secure directory. But it does not resolve file links or eliminate equivalence errors.

public static void main(String[] args) {
  File f = new File("/tmphome/me/" + args[0]);
  String absPath = f.getAbsolutePath();

  if (!isInSecureDir(Paths.get( absPath))) {
    throw new IllegalArgumentException();
  }
  if (!validate(absPath)) {  // Validation
    throw new IllegalArgumentException();
  }		  
}

The application intends to restrict the user from operating on files outside the {{/tmphome/me}} directory and uses a {{validate()}} method to enforce this condition. The path name validation can be easily circumvented.  For example, if the directory were not seucre, an attacker who can create symbolic links in {{/tmphome/me}} can cause the program to pass validation checks by supplying the unresolved path. All file operations performed are reflected in the file pointed to by the symbolic link. If the string {{filename}} is passed as {{argv\[0\]}} and {{/tmphome/me/filename}} is a symbolic link that refers to {{/dirname/filename}} the validation passes.  This is because the root directory of the compiled path name is still {{/tmphome/me}}, but the operations are carried out on the file {{/dirname/filename}}.

...

public static void main(String[] args) throws IOException {
  File f = new File("/tmphome/me/" + args[0]);
  String canonicalPath = f.getCanonicalPath();

  if (!isInSecureDir(Paths.get(canonicalPath))) {
    throw new IllegalArgumentException();
  }
  if (!validate(canonicalPath)) {  // Validation
    throw new IllegalArgumentException();
  }
}

...

A comprehensive way of handling this issue is to grant the application the permissions to operate only on files present within the intended directory — /tmphome/me in this example. This compliant solution specifies the absolute path of the program in its security policy file, and grants java.io.FilePermission with target /tmphome/me and actions read and write.

grant codeBase "file:/home/programpath/" {
  permission java.io.FilePermission "/tmphome/me", "read, write";
};

See rule ENV02-J. Create a secure sandbox using a Security Manager for additional information on using security managersThis solution does require that /home/me must be a secure directory, and associated code should check this requirement and abort if it is not met.

Noncompliant Code Example

...

Noncompliant Code Example

The following code examples assume that /img and /img/java are secure directories.

This noncompliant code example attempts to mitigate the issue by using the File.getCanonicalPath() method, which fully resolves the argument and constructs a canonicalized path. For example, the path /img/../etc/passwd resolves to /etc/passwd. Validation without canonicalization remains insecure because the user can specify files outside the intended directory.

...

// All files in /img/java can be read
grant codeBase "file:/home/programpath/" {
  permission java.io.FilePermission "/img/java", "read";
};

See rule ENV02-J. Create a secure sandbox using a Security Manager for additional information on using security managers.

Risk Assessment

Using path names from untrusted sources without first canonicalizing them and then validating them can result in directory traversal and path equivalence vulnerabilities.

...

...

...