5

I want to use the org.apache.commons.exec Java library to call an executable. Does the CommandLine object protect against command line injection? For example, if I call:

String singleStringArgument = "-whatever;rm -rf ~/*"; // evil looking argument!
CommandLine cl = new CommandLine(new File(pathToExe,exeName)); 

cl.addArgument(singleStringArgument);  // oh no!

Executor exe = new DefaultExecutor();
exe.execute(cl);

would rm -rf ~/* also run in addition to the intended command? If it does, what is the best way to protect against this?

The API says addArgument() "handles quoting" but I'm not sure what that means in this context. I could whip up a test case to see what happens on my linux box, but I want to be sure that it's safe on other platforms too.

Timothy Jones
  • 21,495
  • 6
  • 60
  • 90

3 Answers3

4

; is a feature of the shell. If you don't create a command line around sh -c or something like it, you can't get injected into. It's not that commons is safe, its that you aren't even running the program with the vunerability.

Commons CLI is wrapping the Process class. The Process class is not documented to fire up the shell. It is documented to do an exec with specified arguments of what you tell it to.

As per a comment, one of the wonders of open source is that you can read the source. If version X of commons-CLI does what you like, depend on it, and don't upgrade without rechecking.

bmargulies
  • 97,814
  • 39
  • 186
  • 310
  • I'm not planning to run `sh -c` directly, but I'm concerned that the internals of apache commons might be calling via a system shell in some cases - or do they bypass the shell somehow? In C, I know that calling `system()` with plain input supplied by the user is unsafe, because `system()` calls `/bin/sh -c` with the arguments given. – Timothy Jones Jun 14 '11 at 00:55
  • 1
    If the documentation doesn't explicitly describe the behavior, you could look at the source code -- but then you'd be relying on the implementation rather than the specification. – jdigital Jun 14 '11 at 01:15
1

So you control the command (pathToExe) and are worried only about the argument? How well do you know the command? Is there any chance that it could exec another program? Is there any chance it could do something damaging even without invoking a secondary command? Does the program have any other vulnerabilities (buffer overflow, etc)?

As a general answer, this approach seems iffy to me, especially if you want this to work cross platform. If you know the command to be executed and can constrain the input, then you might be able to squeak by, but personally I wouldn't use this approach unless there was a really good reason to do so.

jdigital
  • 11,926
  • 4
  • 34
  • 51
  • In general I would agree. In this case though, the pathToExe and the executable code itself are known and well tested. If someone malicious has swapped out the real exe in the filesystem for some other malicious exe, well, they'd have enough permissions to do the same with the initial Java. Appreciate the feedback though - I upvoted you :) – Timothy Jones Jun 14 '11 at 01:10
0

My suggestion is to make the program err on the side of safety if possible and only issue commands itself and not dumbly execute command fragments or pass on arguments issued by an end user. There are many variations of injection. ; is one already discussed. You can also use backticks (wrapping rm -rf ~/* in backticks makes the shell interpret it first)The user can also accidently or intentionally invoke aliases. The list of things that can go wrong is endless.

qwerty
  • 3,801
  • 2
  • 28
  • 43