Skip to main content

Inappropriate coding practices - relative path command

Need​

Prevention of security vulnerabilities caused by inappropriate coding practices

Context​

  • Usage of Scala for building scalable and high-performance applications
  • Usage of java.io for input and output operations in Java

Description​

Non compliant code​

import java.io._

def executeCommand() = {
  val pb = new ProcessBuilder("bin/myExecutable")
  pb.directory(new File("."))
  val process = pb.start()
  process.waitFor()
}

In the above Scala code snippet, the function executeCommand() is intended to execute a binary file named myExecutable located in the bin directory relative to the current directory.

The ProcessBuilder class in Java, which is used here, is a utility class to create operating system processes. The ProcessBuilder constructor takes a command and its parameters as input. Here, it is taking a relative path bin/myExecutable as input.

The function pb.directory(new File(".")) sets the working directory. The . denotes the current directory.

The pb.start() starts the process and process.waitFor() waits for the process to complete.

The vulnerability here lies in the use of relative paths. The relative path bin/myExecutable is used to locate the executable file. This is a security risk because an attacker can manipulate the PATH environment variable to point to a malicious executable, thereby compromising the system.

For example, an attacker could place a malicious executable in a directory, add that directory to the PATH, and then trick the application into running the malicious executable instead of the intended one. This could lead to a variety of negative outcomes, such as data loss, data theft, or unauthorized system access.

To mitigate this vulnerability, it is recommended to use absolute paths when referencing executables.

Steps​

  • Avoid using relative paths when referencing executables.
  • Use absolute paths instead to ensure the correct execution of the desired executable.
  • Ensure that the executable being called is located in a secure and trusted location.
  • Validate and sanitize any user input that may be used in constructing the path to the executable.
  • Consider using a whitelist approach to limit the executables that can be called.
  • Regularly update and patch the system to prevent any potential vulnerabilities in the executables.

Compliant code​

import java.io._

def executeCommand() = {
  val pb = new ProcessBuilder("/absolute/path/to/bin/myExecutable")
  pb.directory(new File("/absolute/path/to"))
  val process = pb.start()
  process.waitFor()
}

The updated code now uses an absolute path when referencing the executable, which is a more secure practice than using relative paths. This is because relative paths can be manipulated by an attacker to execute arbitrary code.

In the original code, the ProcessBuilder was given a relative path to the executable. This means that it would look for the executable in the current working directory, which could be anywhere in the system. If an attacker were able to modify the current working directory, they could potentially execute arbitrary code.

In the updated code, we provide an absolute path to the ProcessBuilder. This means that it will only look for the executable in the specified location. This reduces the risk of an attacker being able to execute arbitrary code, as they would need to gain access to the specified directory to modify the executable.

Furthermore, the directory method of the ProcessBuilder is now also given an absolute path. This ensures that the process is started in a known and controlled environment.

It's important to note that the absolute paths used should point to secure and trusted locations. Also, any user input that may be used in constructing the path to the executable should be validated and sanitized to prevent path traversal attacks.

Finally, consider using a whitelist approach to limit the executables that can be called by the application, and regularly update and patch the system to prevent any potential vulnerabilities in the executables.

References​

Last updated on