1

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 ?

2

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.

2
  • There is obviously a potential issue regarding the length of the parameter field, but even data files can be vectors for exploitation - malformed graphics, too long configuration strings, ... – peter ferrie Jul 29 '14 at 18:14
  • Right, assuming this is a server application, even if you can't upload a malformed data file to a predictable file path, you may be able to feed the application a URI or a UNC path to a malformed data file. – Jason Geffner Jul 29 '14 at 18:19
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.