Skip to main content

Insecure Use of Dangerous Function

This vulnerability category covers the following issues:

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:

OS Command Injection

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
  4. Test it and ensure the functionality works as expected

  5. 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
  4. Test it and ensure the functionality works as expected

  5. 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
  4. Test it and ensure the functionality works as expected

  5. Ship it ๐Ÿšข and relax ๐ŸŒด

More information:โ€‹