Command injection prevention for Go

This is a command injection prevention cheat sheet by Semgrep, Inc. It contains code patterns of potential ways to run an OS command in an application. Instead of scrutinizing code for exploitable vulnerabilities, the recommendations in this cheat sheet pave a safe road for developers that mitigate the possibility of command injection in your code. By following these recommendations, you can be reasonably sure your code is free of command injection.

Check your project using Semgrep

The following command runs an optimized set of rules for your project:

semgrep --config p/default

1. Running an OS command

1.A. Running OS commands with exec.Command()

The Command and CommandContext execute commands provided as arguments. If unverified user data can reach its call site, this may end up in a command injection vulnerability. Both Command and CommandContext have built-in protections that do not let command arguments cause trouble. But ensure that the command itself is not controlled by the user, also do not use sh, because internal protection does not work in this case.

Example:

package main

import "os/exec"

func main() {
  // Command example
  cmd := exec.Command("echo", "hello")

  // CommandContext example
  err := exec.CommandContext(ctx, "sleep", "5").Run()

  // Not vulnerable
  cmd := exec.Command("echo", "1; cat /etc/passwd")

  // Vunerable
  userInput :=  "echo 1 | cat /etc/passwd" // value supplied by user input
  out, _ = exec.Command("sh", "-c", userInput).Output()

  // Vulnerable
  userInput1 := "cat" // value supplied by user input
  userInput2 := "/etc/passwd" // value supplied by user input
  out, _ = exec.Command(userInput1, userInput2)
}

References

• Command documentation
• CommandContext documentation

Mitigation

Do not let the user input in exec.Command and exec.CommandContext functions. Alternatively:

• Always try to use internal Go API (if it exists) instead of running an OS command. In other words, use internal language features instead of invoking commands that can be exploited.
• Do not include command arguments in a command string, use parameterization instead. For example:
  Use:

  exec.Command("/path/to/myCommand", "myArg1", inputValue)
  Instead of:

  exec.Command("bash", "-c", "myCommand myArg1 " + inputValue)
• If it is not possible, then strip everything except alphanumeric characters from an input provided for the command string and arguments.
• Try to avoid non-literal values for the command string.
• If it is not possible, then do not let running arbitrary commands, use an allowlist for inputs.

Semgrep rule

go.lang.security.audit.dangerous-exec-command.dangerous-exec-command

1.B. Creating exec.Cmd struct

The Cmd represents an external command that is prepared or run. If unverified user data reaches its call site it can result in a command injection vulnerability. Make sure that the command path and first argument are not controlled by the user, also do not use sh, because internal protection does not work in such a case.

Example:

package main

import (
  "os/exec"
  "os"
)

func main() {
  cmd := &exec.Cmd {
    // Path is the path of the command to run.
    Path: "/bin/echo",
    // Args holds command line arguments, including the command itself as Args[0].
    Args: []string{ "echo", "hello world" },
    Stdout: os.Stdout,
    Stderr: os.Stdout,
  }
  cmd.Start();
  cmd.Wait();

  // Args can be also ommited and {Path} will be used by default
  cmd := &exec.Cmd {
    Path: "/bin/echo"
  }

  // Vulnerable
  userInput := "/pwn/exploit" // value supplied by user input
  cmd := &exec.Cmd {
    Path: userInput
  }

  // Vulnerable
  userInput1 := "/bin/bash" // value supplied by user input
  userInput2 := []string{ "bash", "exploit.sh" } // value supplied by user input
  cmd := &exec.Cmd {
    Path: userInput1,
    Args: userInput2
  }

}

References

• Cmd struct documentation

Mitigation

Do not let the user input in exec.Cmd struct. Alternatively:

• Always try to use internal Go API (if it exists) instead of running an OS command.
• Try to avoid non-literal values for the command string.
• If it is not possible, then do not let running arbitrary commands, use an allowlist for inputs.
• Do not include command arguments in a command string, use parameterization instead. For example:
  Use:

  cmd := &exec.Cmd {
    Path: "/path/to/myCommand",
    Args: []string{ "myCommand", "myArg1", inputValue },
  }
  Instead of:

  cmd := &exec.Cmd {
    Path: "/bin/bash",
    Args: []string{ "bash", "-c", "myCommand myArg1 " + inputValue },
  }
• If it is not possible - strip everything except alphanumeric characters from an input provided for the command string and arguments.

Semgrep rule

go.lang.security.audit.dangerous-exec-cmd.dangerous-exec-cmd

1.C. Writing to a command's StdinPipe

Command's StdinPipe returns a pipe that is connected to the command's standard input when it starts. A command injection vulnerability happens if unverified user data reaches StdinPipe. A malicious actor can inject a malicious script to execute arbitrary code.

Example:

package main

import (
  "fmt"
  "os/exec"
)

func main() {
  cmd := exec.Command("bash")
  // StdinPipe initialization
  cmdWriter, _ := cmd.StdinPipe() 
  cmd.Start()
  // Vulnerability when `password` controlled by user input
  cmdInput := fmt.Sprintf("sshpass -p %s", password)
  // Writing to StdinPipe
  cmdWriter.Write([]byte(cmdInput + "\n"))
  cmd.Wait()
}

References

• Cmd.StdinPipe documentation

Mitigation

Do not let the user input in command's StdinPipe. Alternatively:

• Always try to use internal Go API (if it exists) instead of running an OS command.
• Do not use it to run the bash command and to avoid non-literal values for the command string.
• If it is not possible, then do not let running arbitrary commands, use a white list for inputs.
• Strip everything except alphanumeric characters from an input provided for the StdinPipe input.

Semgrep rule

go.lang.security.audit.dangerous-command-write.dangerous-command-write

1.D. Running OS commands with syscall.Exec()

Execor ForkExec invokes the execve(2) system call. If unverified user data can reach its call site, this is a command injection vulnerability. Make sure that the command is not controlled by the user, also do not run sh with any possibility of user input involved in command arguments.

Example:

package main

import "syscall"
import "os"
import "os/exec"

// Exec invokes the execve(2) system call.
syscall.Exec(binary, args, env)
// ForkExec - combination of fork and exec, careful to be thread safe.
syscall.ForkExec(binary, args, env)

func vulnerableCode(userInput string) {
  //  Vulnerable: Do not let `path` be defined by user input
  path, _ := exec.LookPath(userInput)
  args := []string{"ls", "-a", "-l", "-h"}
  env := os.Environ()
  execErr := syscall.Exec(path, args, env)
}

References

• Exec documentation
• ForkExec documentation

Mitigation

Do not let the user input in syscall.Exec and syscall.ForkExec functions. Alternatively:

• Always try to use internal Go API (if it exists) instead of running an OS command.
• Try to avoid non-literal values for the command string.
• If it is not possible, then do not let running arbitrary commands, use an allowlist for inputs.
• Do not include command arguments in a command string, use parameterization instead. For example:
  Use:

  syscall.Exec("/path/to/myCommand", []string{"myCommand", "myArg1", inputValue}, env)
  Instead of:

  syscall.Exec("/bin/bash", []string{"bash", "-c", "myCommand myArg1 " + inputValue}, env)
• If it is not possible - strip everything except alphanumeric characters from an input provided for the command string and arguments.

Semgrep rule

go.lang.security.audit.dangerous-syscall-exec.dangerous-syscall-exec

---

Not finding what you need in this doc? Ask questions in our Community Slack group, or see Support for other ways to get help.