Insecure Use of Dangerous Function

This vulnerability category covers the following issues:

• Command Injection
• Code Injection
• Denial of Service

Why is this important?

Elixir, like any other programming language, has dangerous functions. If these functions are not used properly, it can have a catastrophic impact on your app. Attacker controlled input, that is processed by any of these functions, can lead to attackers getting full access to your production environment.

Check out this video for a high-level explanation:

Read below to find out how to fix this issue in your code.

Command Injection

The highlighted APIs below are used to execute system commands. If unfiltered input is passed to these APIs, it can lead to arbitrary command execution.

Option A: Use operating system APIs securely

1. Go through the issues that GuardRails identified in the PR.
2. Locate the dangerous function. For example:

  System.cmd(test, [])

or:

  :os.cmd(test, [])

3. Take one of the following actions:

• If the functionality is not required, then remove it.
• Ensure that no user input is processed by the function.
• If user input is processed, ensure that no special characters are allowed. E.g. validate that the user input only contains alphanumeric values.

5. Test it and ensure the functionality works as expected
6. Ship it 🚢 and relax 🌴

Code Injection

Whenever dynamic code is evaluated, attackers have an opportunity to influence the code, which can lead to malicious code execution resulting in data leakage or operating system compromise.

Option A: Use dangerous APIs securely

1. Go through the issues that GuardRails identified in the PR.
2. Locate the following code pattern:

    Code.#{evil_func}(evil_input)

or:

  EEx.#{evil_func}(evil_input)

3. Take one of the following actions:

• If the functionality is not required, then remove it.
• Ensure that no user input is processed by the function.
• If user input is processed, ensure that the accessible functions are limited to expected values. And that the input passed to these functions is validated. E.g. validate that the user input only contains alphanumeric values.

5. Test it and ensure the functionality works as expected
6. Ship it 🚢 and relax 🌴

Denial of Service

In Elixir, atoms are not garbage collected. As such, if user input is used to create atoms it may result in memory exhaustion. Prefer the secure alternatives for untrusted user input.

Option A: Avoid Unsafe Atom Interpolation

1. Go through the issues that GuardRails identified in the PR.
2. Locate the following code pattern:

  # Unsafe usage of String._to_atom
  def index(co  nn, params) do
    render conn, String.to_atom(params["test"])
  end

or:

  # Unsafe usage of List.to_atom
  def index(conn, %{"test" => test}) do
    render conn, List.to_atom(test)
  end

or:

  # Unsafe atom interpolations
  def index(conn, %{"test" => test}) do
    render conn, :"foo\#{test}"
  end

3. And replace them with the secure alternative:

  # Safe usage of String._to_atom
  # and atom interpolations
  def index(co  nn, params) do
    render conn, params["test"])
  end

or:

  # Unsafe usage of List.to_atom
  def index(conn, %{"test" => test}) do
    render conn, List.to_existing_atom(test)
  end

5. Test it and ensure the functionality works as expected
6. Ship it 🚢 and relax 🌴

More information

• CWE-94: Improper Control of Generation of Code ('Code Injection')
• CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
• Common Weakness Enumeration (CWE-78)
• OWASP Top 10 - A1 Injection