0

What are the main kinds of hacks that can be used when passing user input from the command line, and what are the key techniques to prevent against them (like to prevent against browser XSS attacks, you typically escape the HTML before rendering in the DOM).

But for the command-line, I've only just started to think about potential problems and solutions, so wondering if they have been aggregated before, or if we can do so here. Some situations:

  • File paths accessing things outside of a desired folder. So if you want all generated file read/write to occur in the /tmp folder, you need to make sure users don't do /tmp/../usr/stuff to access private folders.
  • Executing subshell commands or piping. I imagine if you have a command like convert {input} {output} (an imagemagick command), you could pass in input: "2> /dev/null", output: "| cat some-os-private-config-file" or perhaps input: "2> /dev/null &&", output: "echo $(which node)" or something. So you would have convert 2> /dev/null && echo $(which node).

So what are the best ways to generically mitigate against these sorts of problems? What are the main things to handle? What to check for basically on each input argument? If it's too complicated, what are the main complexities? What are the key things to be aware of when implementing this system?

Improve this question
8
  • Web applications and command line tools are not comparable. Web applications don't provide users any access to operating system. Where as command line tools have purpose to allow user to interact with the operating system. For command line, it is the purpose to allow usage of any paths, to allow usage of commands piping. Any restrictions are usually done by other means, namely be permissions. Command line tools are executed in user context. Which means that for command to execute some actions, user must have permission for this action. Commented Feb 5, 2024 at 1:35
  • ... All examples what you show are absolutely legitimate. If user should not be able to do particular operations, they should be prohibited on the OS level. Commented Feb 5, 2024 at 1:37
  • "So what are the best ways to generically mitigate against these sorts of problems?" - I don't see any problems. Again, the best way to deal with permissions is to use permission system of particular OS, e.g. standard Linux permissions or SELinux. Commented Feb 5, 2024 at 1:39
  • @mentallurg So I am building a browser/REST API for doing things like convert documents with the pandoc CLI tool, and other things of that nature (there are no easy to use non-CLI tools for these kinds of things). So you're saying I need to make the OS "user" have certain permissions for all my commands (on my remote EC2 instance, for example)? Any chance you could link to relevant solution for that, or explain what I need to do briefly? I am no OS security expert by any means. Commented Feb 5, 2024 at 2:15
  • To the pandoc command I might have to pass a "format" option, so have to validate the format isn't some unknown value. But wondering how much security work I have to do, and of what kind. Some things like formats I check against an enum, but other things like some CLI option which is an arbitrary string, I need to at least limit against some sorts of hacks. Commented Feb 5, 2024 at 2:17

1 Answer 1

Reset to default
2

It is tough to get a hold on any statistics (in regards of the command-line-specific context).

However here are some of the most common attack vectors and their mitigations (unordered, enumerated)

A. AttackVectors and their Mitigations

  1. Command Injection - Strict parsing
  2. Path Traversal - Privilege separation
  3. Argument Injection - Strict parsing
  4. Symlink Attack - Privilege separation
  5. Race Condition - Atomic operations
  6. Input/Output Redirection - Secure file handling
  7. Privilege Escalation via Sudo - Minimize required permissions
  8. Wildcard Expansion - Literal argument handling
  9. Script Injection - Escaping special characters
  10. Environment Variable Manipulation - Environment sanitization
  11. Integer overflow - Larger datatypes, Static Analysis
  12. Buffer overflow - Stack Canaries, DEP, ASLR
  13. Format String Vulnerabilities - Don't use Printf-'Methodfamily'-members

In case your source for the commands to be run is a public / unknown system,
you probably should also consider to:

B. Additional security considerations

  • Try to separate concerns physically (userinput, execution stack on different systems.)

  • Before transferring the commands to the executing system use a formatter-module that string-replaces language-symbols ; {} () [] = == != > < >= <= ! & && || + - * / % ^ " '; ( rendering a not run- but analyzable, secure form that can be used for generating semantic heuristics

  • Important: Deploy a white-listing-strategy to which every distinct invokable command needs to be added to and run against.

  • Don't execute directly, Develop a parser and an execution-helper which can save metadata for long-term machine learning-analysis.

  • Run the executing system in a container inside a hardened SELinux

  • Create a distinct Useraccount with stripped power limited

  • Use a strict least required permission-system.

  • Monitor Logfiles, Diff Sequential Result-History, addCheck for ir-regularities.

  • Setup a simple Reset-command for programmatically cleaning the system that was under attack.

Improve this answer
1
  • Thank you very much, this is exactly what I was looking for. Commented Feb 5, 2024 at 10:09

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.