Wiki Markup |
---|
According to the Java API \[[API 06|AA. Java References#API 06]\], class {{java.io.File}}: |
A pathname, whether abstract or in string form, may be either absolute or relative. An absolute pathname is complete in that no other information is required in order to locate the file that it denotes. A relative pathname, in contrast, must be interpreted in terms of information taken from some other pathname.
An absolute path may sometimes contain aliases, shadows, symbolic links and shortcuts as opposed to canonical paths, which refer to actual files or directories that these point to. These path names must be fully resolved before any file validation operations are performed. For instance, resolving a symbolic link called trace
may yield its actual path on the file system, such as, /home/system/trace
.
The process of canonicalizing file names also makes it safer easier to verify a path, directory, or file name by making it easier to compare names. This is because extraneous characters are eliminated during canonicalization.
Noncompliant Code Example
...
This noncompliant code example accepts the file path as a command line argument and uses the getAbsolutePath()
method to obtain the absolute file path. This method does not automatically resolve symbolic links.
Wiki Markup |
---|
argument. Let {{argv\[0\]}} be the string {{java/dirname/filename}}, where {{/tmp/java/}} is a symbolic link that points to anotherthe file in some directory of directory {{/dirname/}} present on the local file system. The Onapplication POSIXdesires basedto systems,restrict the {{getAbsolutePath()}} method includes user from operating on files outside the {{/tmp/java}} (namedirectory ofand theuses symbolic link) in the path that it returnsa {{validate()}} method to enforce this condition. An adversary who can create symbolic links in {{/tmp}} can cause the program to pass validation checks but operate on the wrong target file. On Windows and Macintosh systems, this behavior is not observed. The symbolic link is fully resolved on these platforms. This implies implementation defined behavior by supplying the unresolved path. After the validation, any file operations performed are reflected in the file pointed to by the symbolic link. If an attacker enters an unresolved input such as {{java/dirname/filename}}, the validation will pass because the root directory of the compiled path name is still {{/tmp}}, but the operations will be carried out on the file {{/dirname/filename}}. |
On Windows and Macintosh systems, this behavior is not observed. The symbolic link, aliases and short cuts are fully resolved on these platforms.
Code Block | ||
---|---|---|
| ||
public static void main(String[] args) { File f = new File("/tmp/" + args[0]); String absPath = f.getAbsolutePath(); if(!absPath.equals("/tmp/java"validate(absPath)) { // Validation throw new IllegalArgumentException(); } } |
...
This compliant solution uses the getCanonicalPath()
method, introduced in Java 2, because it resolves the aliases, shortcuts or symbolic links consistently, across all platforms. The value of the alias (if any) is not included in the returned value. Moreover, relative references like the double period (..) are also removed so that the input is reduced to a canonicalized form before validation is carried out. The getCanonicalPath()
method throws a security exception when used within applets as it reveals too much information about the host machine. The getCanonicalFile()
method behaves like getCanonicalPath()
but returns a new File
object instead of a String
Consequently, this compliant solution is also compliant with IDS18-J. Prevent against directory traversal attacks in that, an adversary cannot use ../
sequences to break out of the specified directory when the validate()
method is present.
Code Block | ||
---|---|---|
| ||
public static void main(String[] args) throws IOException { File f = new File("/tmp/" + args[0]); String canonicalPath = f.getCanonicalPath(); if(!canonicalPath.equals("/tmp/java"validate(canonicalPath)) { // Validation throw new IllegalArgumentException(); } } |
The getCanonicalPath()
method throws a security exception when used within applets as it reveals too much information about the host machine. The getCanonicalFile()
method behaves like getCanonicalPath()
but returns a new File
object instead of a String
.
Compliant solution
A comprehensive way of handling this issue is to grant the application the permissions to operate on files present only within /tmp
. This can be achieved by specifying the absolute path of the program in the security policy file and granting the java.io.FilePermission
with the target name as /tmp
and the actions as read
and write
. This is shown below.
Code Block | ||
---|---|---|
| ||
grant codeBase "file:/home/programpath/" {
permission java.io.FilePermission "/tmp", "read, write";
};
|
The guideline ENV30-J. Create a secure sandbox using a Security Manager contains more information on using a security managerThis compliant solution is also compliant with IDS18-J. Prevent against directory traversal attacks.
Risk Assessment
Using path names from untrusted sources without first canonicalizing the filenames may result in operations being carried out on the wrong filesmakes it difficult or impossible to validate file names and paths.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
FIO00- J | medium | unlikely | medium | P4 | L3 |
...