Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rule Request: UnnecessaryShellCommand #1435

Open
mcandre opened this issue Nov 20, 2018 · 5 comments
Open

Rule Request: UnnecessaryShellCommand #1435

mcandre opened this issue Nov 20, 2018 · 5 comments

Comments

@mcandre
Copy link

mcandre commented Nov 20, 2018

As an engineer, I want to be warned early when my application code is trying to shell out for things that libraries already provide, such as:

  • curl/wget (Can probably use a URL request)
  • sed/awk/gawk/nawk (Can just use a regular expression)
  • jq (Can use a JSON marshaller)

This rule would encourage more performant applications, remove dependencies on unnecessary software components, reduce attack surfaces, and increase cross-platform support, by avoiding relying on platform-specific shell command syntax.

Example triggers:

  • Supplying a process object with a launch path ending with curl, wget, sed, awk, jq, jq.exe, etc.

Example non-triggers:

  • Supplying a process object with an argument of curl, wget, sed, awk, jq, jq.exe, etc. While there are plenty of cases where these would constitute unnecessary shell commands, such as /usr/bin/env curl... or exec wget..., the false positives for such commands are unfortunately more numerous than the true positives.

This rule should contain a limited number of common shell commands, such as those listed above. We can add more over time. Configuration for this rule should be able to customize which of these command patterns is relevant to the user's application needs.

As a security concern, this rule can reasonably become a default rule, as shelling out introduces additional security risks, including shell injections, compared to sticking to pure library code.

I would be happy to see this rule be included in reek's available suite of checks, and if we find we're happy to apply it in a lot of places, then we can always turn it on by default later.

@troessner
Copy link
Owner

I like it! Are you up for a pull request? If yes, we'd guide you through it ;)
If not that's fine as well, it just might take us a while before we could tackle this.

@mvz
Copy link
Collaborator

mvz commented Nov 21, 2018

As a security concern, this rule can reasonably become a default rule, as shelling out introduces additional security risks, including shell injections, compared to sticking to pure library code.

Doesn't this mean it's best to flag all shelling out as dangerous? That would make sense to me.

@mcandre
Copy link
Author

mcandre commented Jan 6, 2019

Not quite. There are plenty of valid reasons to invoke a shell command, such as Vagrant does, providing a convenient wrapper around VirtualBox and other VM's. However, many uses of shelling out are entirely superfluous, such as using awk from Ruby, or Perl.

@mvz
Copy link
Collaborator

mvz commented Jan 7, 2019

Yes of course, but how will we know the difference? We could add calling any ruby programs instead of using their libraries.

What I'm thinking of here is forcing the user to disable this rule for their specific, hopefully valid, use case.

@mcandre
Copy link
Author

mcandre commented Mar 2, 2019

Calling a Ruby program from another Ruby program is forgivable, though ideally the authors provide a Ruby library as well, in order to avoid unnecessary overhead.

There are plenty of exceptions, especially where no library exists, and so I propose this rule as definitely optional, and likely disabled by default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants