Imagine that we have the following pseudo-code in a Windows application:
ShellExecuteA(0, "open", &File, &Parameters, &Directory, 1);
And, imagine that you can gain control over the Parameters argument. Does that mean it is exploitable ?
I know that ShellExecute() is vulnerable to command injection. But, in this case, is it also vulnerable in the same manner ?
It depends on the lpFile argument. If lpFile is a command-line interpreter (such as cmd.exe or powershell.exe) or a program that can accept code as a command line argument (such as perl.exe or ruby.exe), then yes, you could supply arbitrary commands for a command injection attack.
However, if the lpFile program doesn't execute command line arguments (for example, notepad.exe, pbrush.exe, etc.), then there is no command injection vulnerability. Note that even in these cases though, if the lpFile program tries to open the file path supplied in the command line, this could still be seen as a security issue.
As Jason already mentioned, everything depends on file. But I want to say something more.
You said:
And, imagine that you can gain control over the Parameters argument. Does that mean it is exploitable ?
In the same manner control of other ShellExecute parameters might be gain... You probably understand why I said might, not can.
You didn't included info in question, but I think you meant that control of parameters is gained editing executable. If so there is such thing.
Imagine file is cmd.exe and you can control parameters, but in app parameter is C:\file.txt it has 11 characters, so you could change it into some other up-to 11 characters parameter (if it is smaller then 11, you need to add NULLs).
However in real situations ShellExecute parameters are partially hard-coded and are build dynamically during program flow. So answering to your question, ShellExecute is vulnerable to command injection, however, not every app that uses ShellExecute could be taken as a target and actual injecting could be not so easy task.
