Runtime.getRuntime().exec(String[]) safety

Question

I'm using Runtime.getRuntime().exec(String[]) to run processes where some of the elements of the String array are defined by the user.

Is this safe? Or will it allow to inject code into the terminal?

If it isn't safe what can i do to avoid code injection? (it has to be platform independent)

Burschenschaft

Answer 1

As i mentioned in a comment on another answer (might as well add my own answer), this should be safe as long as you control the first argument.

Ilyssa

Thanks for the answer. It seams that your are right, as long as the first argument is controlled, it should be safe. I will need to investigate this further. – Burschenschaft

Answer 2

Generally this isn't safe since it should be possible to execute shell scripts (which might be malicious).

I'd allow a predefined set of commands which you know and let the user select one of those (with optional parameters that might be escaped somehow) instead of allowing to enter the commands completely.

Canso

@Canso thank you for the answer. I'm already doing something like that. The first element of the array is always defined by me, but I'm still unsure if a user can do something like ["MyProcess", "expected parameter & rm -Rf *"] or other command in any operating system. – Burschenschaft

@Jose - if you control the first argument and are using the String[] exec method, then you should be safe (assuming the program you are running doesn't do anything unsafe with the parameters it gets). – Ilyssa

Well, you can't be sure for any operating system, but you might be able to escape the parameters using quotes like expected parameter & rm -Rf * -> "expected parameter & -RF *" (from the shell's point of view) i.e. replace all existing quotes using the platform dependent escape expression and then wrap the parameter with additional quotes. Escaping might be platform dependent, but if you add support for the most common platforms you should be fine. – Canso

Another note: If what you are developing is a library or tool, you should definitely document this well and provide for security options that the implementor/user might set (potentiall depending on the platform). – Canso

@Canso - why can't you be sure? java does not execute a shell when calling exec. that's what causes a lot of confusion for first time users of the method (because it is not doing all the normal shell magic). and, if you know how to quote for a given platform, you probably know how exec will work on that platform anyway. – Ilyssa

Well, you don't know exactly how a specific JVM implementation actually invokes the process. But you're right in that normally the shell is not used for executing commands nor should it be offered to be selected by the user with the actual command being the parameter. Additionally, you could override SecurityManager#checkExec() to only allow a specified set of commands. – Canso

@Ilyssa Unfortunately I don't know how it works, it doesn't allow the user to use commands like "&"? I was doing some tests and it doesn't seam to allow, but I believe that the users have more imagination than me. For example, it seams to allow more than one parameter per element of the array, I can't image what malicious user can do with that... – Burschenschaft

The problem is that there is no safe way to prevent code injection for every possible OS since this depends on the OS and how exec is implemented in the JVM used. Thus you could provide some level of security for standard OSs but you'd need to rely on the users/administrators to take care of the more specific options. – Canso

Answer 3

Assuming your user is supplying arguments, ProcessStarter is your friend. A small tutorial on how to use it can be found at https://www.java-tips.org/java-se-tips-100019/88888889-java-util/426-from-runtimeexec-to-processbuilder.html

Holcman

Thanks for the answer. That's interesting, I will have to have a deeper look at that. I'm already executing the commands in different threads but that solution seams worth investigating. Thanks – Burschenschaft

Answer 4

I think the safety in this case is defined by the underlying operating system access control. If you are using unix and running your script as a limited user, then you should be fine. So as long as the access control is defined correctly and the script is run as a user with correct permission, then it is fine. (but what use case made you write a program like this. )

Estafette

Thanks for the answer. I'm using unix to test the project but when my part is finished it will be out of my hands, so it can be deployed in windows or other OS. I cannot control if it will be correctly deployed with the right permissions, that's what I'm afraid of. If I can control the code injection from my code I would be more relieved. – Burschenschaft

Answer 5

All of these comments seem to be missing one important fact. Command injection is only ONE of the dangers of using user defined arguments with exec. Another possible attack is argument injection. You need to be aware of all possible arguments to a command you are letting a user call.

An example of a dangerous command is find. A user could add the option -exec as an argument to gain arbitrary command execution.

Neptunian