Update: Arshan Dabirsiaghi noted that if you use cmd.exe, /bin/sh, or any other equivalently chainable executable loader, you can still introduce command injection vulnerabilities in .NET in Java. See the Webgoat lesson for an example of this.
Rudolph Araujo pointed out an interesting security note on MSDN about the CreateProcess function (which is called by Process.Start()) regarding the fact that unintended executables may be executed if there is whitespace in the path.
Dan Cornell made two really cool test projects for Java and .NET. Both of them demonstrated that a healthy set of shell meta-characters are ineffective at introducing new commands into system calls in Java and .NET.
System calls should probably be avoided in any case, since the executables aren’t constrained by the security features of managed languages. However, it certainly seems like this threat is pretty well mitigated in these platforms, at least until someone finds a vulnerability.
Original:
Command injection (also called shell injection) can be a huge problem. Recently, I was working on an old Perl/CGI system that allowed command injection through the system command that ultimately led to a reverse shell on the web server.
I was trying to develop some examples of command injection in .NET, using the Process.Start method. The Process.Start method takes a file and arguments as parameters. You can’t specify additional commands through meta-characters like semi-colons (;) and pipes (|). Java seems to be similarly invulnerable – according to this OWASP page:
There are many sites that will tell you that Java’s Runtime.exec is exactly the same as C’s system function. This is not true. Both allow you to invoke a new program/process. However, C’s system function passes its arguments to the shell (/bin/sh) to be parsed, whereas Runtime.exec tries to split the string into an array of words, then executes the first word in the array with the rest of the words as parameters. Runtime.exec does NOT try to invoke the shell at any point. The key difference is that much of the functionality provided by the shell that could be used for mischief (chaining commands using “&”, “&&”, “|”, “||”, etc, redirecting input and output) would simply end up as a parameter being passed to the first command, and likely causing a syntax error, or being thrown out as an invalid parameter.
Obviously, if you let the user specify the first argument (the file name) then you are in trouble, but that’s not really injection. Additionally, if you get into native/unmanaged code in your app you lose any protection. Those caveats aside, are Java and .NET impervious to command injection?
