Baseline for Ed 2 of tr 24772

7.29 Unquoted Search Path or Element [XZQ]

7.29.1 Description of application vulnerability

Strings injected into a software system that are not quoted can permit an attacker to execute arbitrary commands.

7.29.2 Cross reference

CWE:

428. Unquoted Search Path or Element

CERT C guidelines: ENV04-C

7.29.3 Mechanism of failure

The mechanism of failure stems from missing quoting of strings injected into a software system. By allowing white-spaces in identifiers, an attacker could potentially execute arbitrary commands. This vulnerability covers "C:\Program Files" and space-in-search-path issues. Theoretically this could apply to other operating systems besides Windows, especially those that make it easy for spaces to be in filenames or folders names.

7.29.4 Avoiding the vulnerability or mitigating its effects

Software developers can avoid the vulnerability or mitigate its ill effects in the following ways:

• 
  Use sSoftware thatshould quotes the all string input data that can be potentially executed on a system.
  
• 
  
  
• 
  Use a programming language that enforces the quoting of strings.
  

7.30 Discrepancy Information Leak [XZL]

7.30.1 Description of application vulnerability

A discrepancy information leak is an information leak in which the product behaves differently, or sends different responses, in a way that reveals security-relevant information about the state of the product, such as whether a particular operation was successful or not.

7.30.2 Cross reference

CWE:

203. Discrepancy Information Leaks

204. Response Discrepancy Information Leak
206. Internal Behavioural Inconsistency Information Leak
207. External Behavorial Inconsistency Information Leak
208. Timing Discrepancy Information Leak

7.30.3 Mechanism of failure

A response discrepancy information leak occurs when the product sends different messages in direct response to an attacker's request, in a way that allows the attacker to learn about the inner state of the product. The leaks can be inadvertent (bug) or intentional (design).

A behavioural discrepancy information leak occurs when the product's actions indicate important differences based on (1) the internal state of the product or (2) differences from other products in the same class. Attacks such as OS fingerprinting rely heavily on both behavioural and response discrepancies. An internal behavioural inconsistency information leak is the situation where two separate operations in a product cause the product to behave differently in a way that is observable to an attacker and reveals security-relevant information about the internal state of the product, such as whether a particular operation was successful or not. An external behavioural inconsistency information leak is the situation where the software behaves differently than other products like it, in a way that is observable to an attacker and reveals security-relevant information about which product is being used, or its operating state.

A timing discrepancy information leak occurs when two separate operations in a product require different amounts of time to complete, in a way that is observable to an attacker and reveals security-relevant information about the state of the product, such as whether a particular operation was successful or not.

7.30.4 Avoiding the vulnerability or mitigating its effects

Software developers can avoid the vulnerability or mitigate its ill effects in the following ways:

• 
  Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. 
  

Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.

7.31 Path Traversal [EWR]

7.31.1 Description of application vulnerability

The software constructs a path that contains relative traversal sequence such as ".." or an absolute path sequence such as "/path/here." Attackers run the software in a particular directory so that the hard link or symbolic link used by the software accesses a file that the attacker has under their control. In doing this, the attacker may be able to escalate their privilege level to that of the running process.

7.31.2 Cross reference

CWE:

22. Path Traversal

24. Path Traversal: - '../filedir'

25. Path Traversal: '/../filedir'

26. Path Traversal: '/dir/../filename’

27. Path Traversal: 'dir/../../filename'

28. Path Traversal: '..\filename'

29. Path Traversal: '\..\filename'

30. Path Traversal: '\dir\..\filename'

31. Path Traversal: 'dir\..\filename'

32. Path Traversal: '...' (Triple Dot)

33. Path Traversal: '....' (Multiple Dot)

34. Path Traversal: '....//'

35. Path Traversal: '.../...//'

37. Path Traversal: ‘/absolute/pathname/here’

38. Path Traversal: ‘ \absolute\pathname\here’

39. Path Traversal: 'C:dirname'

40. Path Traversal: '\\UNC\share\name\' (Windows UNC Share)

61. UNIX Symbolic Link (Symlink) Following

62. UNIX Hard Link

64. Windows Shortcut Following (.LNK)

65. Windows Hard Link

CERT C guidelines: FIO02-C

7.31.3 Mechanism of failure

There are two primary ways that an attacker can orchestrate an attack using path traversal. In the first, the attacker alters the path being used by the software to point to a location that the attacker has control over. Alternatively, the attacker has no control over the path, but can alter the directory structure so that the path points to a location that the attacker does have control over.

For instance, a software system that accepts input in the form of: '..\filename', '\..\filename', '/directory/../filename', 'directory/../../filename', '..\filename', '\..\filename', '\directory\..\filename', 'directory\..\..\filename', '...', '....' (multiple dots), '....//', or '.../...//' without appropriate validation can allow an attacker to traverse the file system to access an arbitrary file. Note that '..' is ignored if the current working directory is the root directory. Some of these input forms can be used to cause problems for systems that strip out '..' from input in an attempt to remove relative path traversal.

There are several common ways that an attacker can point a file access to a file the attacker has under their control. A software system that accepts input in the form of '/absolute/pathname/here' or '\absolute\pathname\here' without appropriate validation can also allow an attacker to traverse the file system to unintended locations or access arbitrary files. An attacker can inject a drive letter or Windows volume letter ('C:dirname') into a software system to potentially redirect access to an unintended location or arbitrary file. A software system that accepts input in the form of a backslash absolute path without appropriate validation can allow an attacker to traverse the file system to unintended locations or access arbitrary files. An attacker can inject a Windows UNC (Universal Naming Convention or Uniform Naming Convention) share ('\\UNC\share\name') into a software system to potentially redirect access to an unintended location or arbitrary file. A software system that allows UNIX symbolic links (symlink) as part of paths whether in internal code or through user input can allow an attacker to spoof the symbolic link and traverse the file system to unintended locations or access arbitrary files. The symbolic link can permit an attacker to read/write/corrupt a file that they originally did not have permissions to access. Failure for a system to check for hard links can result in vulnerability to different types of attacks. For example, an attacker can escalate their privileges if he/she can replace a file used by a privileged program with a hard link to a sensitive file, for example, etc/passwd. When the process opens the file, the attacker can assume the privileges of that process.

A software system that allows Windows shortcuts (.LNK) as part of paths whether in internal code or through user input can allow an attacker to spoof the symbolic link and traverse the file system to unintended locations or access arbitrary files. The shortcut (file with the .lnk extension) can permit an attacker to read/write a file that they originally did not have permissions to access.

Failure for a system to check for hard links can result in vulnerability to different types of attacks. For example, an attacker can escalate their privileges if he/she can replace a file used by a privileged program with a hard link to a sensitive file (such as etc/passwd). When the process opens the file, the attacker can assume the privileges of that process or possibly prevent a program from accurately processing data in a software system.

A sanitizing mechanism can remove characters such as ‘.' and ‘;' which may be required for some exploits. An attacker can try to fool the sanitizing mechanism into "cleaning" data into a dangerous form. Suppose the attacker injects a ‘.' inside a filename (say, "sensi.tiveFile") and the sanitizing mechanism removes the character resulting in the valid filename, "sensitiveFile". If the input data are now assumed to be safe, then the file may be compromised.

When two or more users, or a group of users, have write permission to a directory, the potential for sharing and deception is far greater than it is for shared access to a few files. The vulnerabilities that result from malicious restructuring via hard and symbolic links suggest that it is best to avoid shared directories.

Securely creating temporary files in a shared directory is error-prone and dependent on the version of the runtime library used, the operating system, and the file system. Code that works for a locally mounted file system, for example, may be vulnerable when used with a remotely mounted file system.

The mitigation should be centered on converting relative paths into absolute paths and then verifying that the resulting absolute path makes sense with respect to the configuration and rights or permissions. This may include checking white-lists and black-lists, authorized super user status, access control lists, or other fully trusted status.

7.31.4 Avoiding the vulnerability or mitigating its effects

Software developers can avoid the vulnerability or mitigate its ill effects in the following ways:

• 
  Assume all input is malicious. Attackers can insert paths into input vectors and traverse the file system.
  
• 
  Use an appropriate combination of black-lists and white-lists to ensure only valid and expected input is processed by the system.
  
• 
  Use sanitizers to scrub input for sensitive programs. Ensure that sanitizers work properly (e.g. a sanitizer should remove “.” or “..” at a string beginning, but not in the middle of a valid file system address.
  
• 
  A sanitizing mechanism can remove characters such as ‘.' and ‘;' which may be required for some exploits. An attacker can try to fool the sanitizing mechanism into "cleaning" data into a dangerous form. Suppose the attacker injects a ‘.' inside a filename (say, "sensi.tiveFile") and the sanitizing mechanism removes the character resulting in the valid filename, "sensitiveFile". If the input data are now assumed to be safe, then the file may be compromised.
  
• 
  Compare multiple attributes of the file improves the likelihood that the file is the expected one. Files can often be identified by other attributes in addition to the file name, for example, by comparing file ownership or creation time. Information regarding a file that has been created and closed can be stored and then used later to validate the identity of the file when it is reopened.
  
• 
  Follow the principle of least privilege when assigning access rights to files.
  
• 
  Deny access to a file can prevent an attacker from replacing that file with a link to a sensitive file.
  
• 
  Ensure good compartmentalization in the system to provide protected areas that can be trusted.
  
• 
  Restrict the use of shared directories, using in preference files pulled from configuration management systems.When two or more users, or a group of users, have write permission to a directory, the potential for sharing and deception is far greater than it is for shared access to a few files. The vulnerabilities that result from malicious restructuring via hard and symbolic links suggest that it is best to avoid shared directories.
  
• 
  Do not permit temporary files to be created in shared directories.
  

Securely creating temporary files in a shared directory is error-prone and dependent on the version of the runtime library used, the operating system, and the file system. Code that works for a locally mounted file system, for example, may be vulnerable when used with a remotely mounted file system.

The mitigation should be centered on converting relative paths into absolute paths and then verifying that the resulting absolute path makes sense with respect to the configuration and rights or permissions. This may include checking white-lists and black-lists, authorized super user status, access control lists, or other fully trusted status.