Skip to content

Latest commit

 

History

History
87 lines (71 loc) · 7.62 KB

File metadata and controls

87 lines (71 loc) · 7.62 KB

Attack Tree Analysis for sharkdp/fd

Objective: Gain unauthorized access to files/information OR cause DoS via fd

Attack Tree Visualization

Attacker's Goal: Gain unauthorized access to files/information OR cause DoS via fd

├── 1. Unauthorized File Access │ ├── 1.1. Bypass Access Controls (M) [HIGH RISK] │ │ ├── 1.1.1. Application improperly uses fd's output without sanitization or validation. (E) [CRITICAL] │ │ │ └── Example: Application uses fd to list files and directly displays the output to a user without checking permissions. │ │ └── 1.1.4 Application uses fd with --absolute-path and does not properly validate the output, leading to potential path traversal. (M, E) [CRITICAL] │ │ └── Example: Application uses fd --absolute-path and then uses the resulting path in a file operation without sanitization. └── 3. Command Injection (M, E) [HIGH RISK] ├── 3.1. Application uses fd's output as input to another command without proper escaping or sanitization. [CRITICAL] │ └── Example: Application uses fd to find files and then uses the output directly in a shell command. ├── 3.2. Application uses fd with --exec or --exec-batch and does not properly validate the command or arguments. [CRITICAL] └── Example: Application allows users to specify the command to be executed by --exec.

  • 1.1 Bypass Access Controls (Misconfiguration)

    • 1.1.1. Application improperly uses fd's output without sanitization or validation. (Exploit) [CRITICAL]

      • Description: The application uses the output of fd (e.g., a list of filenames) without properly validating or sanitizing it. This can lead to various vulnerabilities, including unauthorized file access and information disclosure.
      • Attack Scenario:
        1. The application uses fd to list files in a directory based on user input.
        2. The attacker provides crafted input (e.g., ../../etc/passwd) that attempts to traverse directories outside the intended scope.
        3. The application does not validate the input and passes it directly to fd.
        4. fd returns the path to the requested file (/etc/passwd).
        5. The application then uses this path to access and potentially display the contents of the file to the attacker.
      • Mitigation:
        • Implement strict input validation to ensure that user-provided input conforms to expected patterns and does not contain directory traversal sequences (e.g., ../).
        • Use a whitelist approach to allow only specific characters and patterns in the input.
        • Sanitize the output of fd before using it in any file operations or displaying it to the user.
        • Consider using a dedicated API or library for file system operations that provides built-in security mechanisms.
    • 1.1.4 Application uses fd with --absolute-path and does not properly validate the output, leading to potential path traversal. (Misconfiguration, Exploit) [CRITICAL]

      • Description: The application uses the --absolute-path option with fd and then uses the resulting absolute paths in file operations without proper validation. This can allow an attacker to access files outside the intended directory.
      • Attack Scenario:
        1. The application uses fd --absolute-path to find files based on user input.
        2. The attacker provides input designed to manipulate the search, such as a pattern that matches a file in a different directory.
        3. fd returns the absolute path to the attacker-controlled file (e.g., /var/www/uploads/../../../etc/passwd).
        4. The application uses this absolute path directly in a file operation (e.g., reading or writing the file) without sanitizing it.
        5. The attacker gains access to the sensitive file (/etc/passwd).
      • Mitigation:
        • Validate the absolute paths returned by fd before using them. Ensure that they fall within the expected directory structure.
        • Use a "chroot jail" or similar mechanism to restrict the application's file system access to a specific directory.
        • Avoid using --absolute-path if possible. If relative paths are sufficient, use them instead.
        • Sanitize the output of fd before using it.
  • 3.1. Application uses fd's output as input to another command without proper escaping or sanitization. [CRITICAL]

    • Description: The application uses the output of fd (e.g., a list of filenames) as input to another command (e.g., a shell command) without properly escaping or sanitizing the output. This is a classic command injection vulnerability.
    • Attack Scenario:
      1. The application uses fd to find files matching a user-provided pattern.
      2. The application then uses the output of fd directly in a shell command, such as: rm $(fd <user_input>)
      3. The attacker provides input containing shell metacharacters, such as: *.txt; rm -rf /
      4. The shell command becomes: rm $(fd *.txt; rm -rf /)
      5. fd finds files ending in .txt.
      6. The shell then executes rm -rf /, deleting the entire file system (or as much as the user running the application has permissions to delete).
    • Mitigation:
      • Never use the output of fd directly in a shell command without proper escaping.
      • Use a language-specific API for executing commands that allows you to pass arguments separately from the command itself. This prevents shell interpretation of the arguments. For example, in Python, use subprocess.run with a list of arguments instead of a single string.
      • If you must use a shell, use a library function that properly escapes shell metacharacters.
      • Avoid using a shell entirely if possible.
  • 3.2. Application uses fd with --exec or --exec-batch and does not properly validate the command or arguments. [CRITICAL]

    • Description: The application uses the --exec or --exec-batch options of fd to execute commands on the found files, but it does not properly validate the command or arguments, allowing an attacker to inject arbitrary commands.
    • Attack Scenario:
      1. The application allows users to specify a search pattern and a command to be executed on the matching files using fd --exec.
      2. The attacker provides a malicious command, such as: fd . --exec "rm -rf /"
      3. The application passes this command directly to fd.
      4. fd executes the attacker's command (rm -rf /) on all found files.
      5. The attacker's command deletes the file system (or as much as it can).
    • Mitigation:
      • Avoid using --exec or --exec-batch with user-provided input if at all possible.
      • If you must use these options with user input, implement a strict whitelist of allowed commands and arguments. Do not allow arbitrary commands.
      • Thoroughly sanitize and validate any user input that is used as part of the command or arguments.
      • Consider using a safer alternative to --exec, such as processing the output of fd within the application's code and using a secure API to perform the desired actions on the files.