Avoiding OS Injection

Never execute system commands from an application.

  • Creating an application that exploits existing tools allows faster development, but the risk is gigantic.

Be careful about imported dependencies, if you need to execute system commands from an application, process all inputs before the command executes and assume a potential vulnerability.

Strategies:

  • Only allow a subset of commands and arguments.

  • Forbid specific commands or characters.

  • Escape special characters.

It is complex to consider all possible situations for the environments where an application may execute. Loopholes may appear in the future.

  • regex frequently only parses the first line (text up to 0x20) and ignores the rest.

  • rm can be written as r’m’ or r”m” or r\m or $'\x72\x6d’ or $(xxd -r -p <<< 726d) or xargs -I {} bash -c '{}m' <<< r.

Drop privileges to a non-privileged user (nobody).

  • The user should only have access to its work files.

    • Difficult to implement as there are many world-readable/executable files.

  • This will limit the impact on the permissions associated with the user.

Isolate execution using virtualization/containers/sandboxes.

  • Will limit the impact to the virtualized/constrained environment.

  • Virtual Machines provide broad isolation but still may present a wide surface.

  • Containers typically provide less attack surface (less tools available).

  • Sandboxes can be very restrictive (SELinux, AppArmor...).

Do not rely on well-known mechanisms such as the PATH.

  • Use absolute paths for all commands.

Last updated