CS.UNSAFE.SEARCH_PATH

Use of search path to resolve absolute Path

When an application searches for critical resources by using an externally-supplied search path (usually by using a search-path variable) that path can point to resources that are not under the application's direct control. This might allow attackers to execute their own programs, access unauthorized data files, or modify a configuration in unexpected ways. If an application uses a search path to locate critical resources such as programs, then an attacker could modify that search path to point to a malicious program, which the targeted application would then execute.

The CS.UNSAFE.SEARCH_PATH checker flags code where a hard-coded relative path is assigned to a variable that can be used as a parameter for routines that invoke external processes.

Vulnerability and risk

If an attacker can modify the $PATH variable to point to a malicious binary and cause the program to be executed in their environment, then the malicious binary will be loaded instead of the one intended. This malicious binary will then run with the privileges of the program, which could possibly give the attacker complete control of the system. Some of the most common variants of untrusted search path are the following:

  • In various UNIX and Linux-based systems, the PATH environment variable may be consulted to locate executable programs, and LD_PRELOAD may be used to locate a separate library.
  • In various Microsoft-based systems, the PATH environment variable is consulted to locate a DLL, executable file, directory etc. , if these are not found in other paths that appear earlier in the search order.

With this sort of opportunity, an attacker could:

  • provide unexpected values and cause a program crash
  • cause excessive resource consumption
  • read confidential data
  • use malicious input to modify data or alter control flow
  • execute arbitrary commands
  • run any process that an attacker may want to run

Mitigation and prevention

Whenever possible, avoid using relative paths in your application. Also, it's best to add validation code before raw input is used as a pathname. The validation code must contain checks for the following cases:

  • dot-dot-slash (../): Using this sequence and its variations, an attacker could navigate your file system and obtain access to any file. Note that (../) can be presented in various encodings, for example, " ../../../etc/shadow" .
  • absolute paths: Using absolute paths in a situation when relative paths are expected could also provide access to arbitrary files in your system, for example, "/etc/shadow".
  • null symbol : Using the null symbol may allow an attacker to truncate a generated file name to widen the scope of attack in a situation when an application restricts possible file extensions by checking or by appending specific extension, for example, "application.cfg%00.pdf".

Vulnerable code example

Copy 
   using System.IO;
   namespace Example
   {
       System.Diagnostics.Process ExternalProcess = new System.Diagnostics.Process();
       ExternalProcess.StartInfo.FileName = "dir"; // Because the path is relative, the PATH environment variable will be used to resolve full path.
       ExternalProcess.StartInfo.Arguments = secretDirectoryPath;
       ExternalProcess.Start();
       ExternalProcess.WaitForExit();
   }

In this example, Klocwork reports a defect at line 8, where we attempt to start a process whose 'FileName' property contains a hard-coded relative path. In this case, a potentially unsafe file is used to start a process, which could be exploited by a malicious user.

Fixed code example

Copy 
   using System.IO;
    
   namespace Example
   {
       System.Diagnostics.Process ExternalProcess = new System.Diagnostics.Process();
       ExternalProcess.StartInfo.FileName = "C:\\absolute_path\\filename.dat";
       ExternalProcess.StartInfo.Arguments = secretDirectoryPath;
       ExternalProcess.Start();
       ExternalProcess.WaitForExit();
  }

In the fixed code example, Klocwork doesn't report an issue at line 8, because 'FileName' is assigned an absolute path and there is no need for the system to resolve the path.

Related checkers

External guidance

Security training

Application security training materials provided by Secure Code Warrior.