Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] prefer child_process.execFile() to child_process.exec() #447

Open
bolinfest opened this issue Sep 5, 2023 · 2 comments
Open

[BUG] prefer child_process.execFile() to child_process.exec() #447

bolinfest opened this issue Sep 5, 2023 · 2 comments
Labels

Comments

@bolinfest
Copy link

Describe the bug
Building up a command string using user-provided arguments and passing it to child_process.exec() runs the risk of shell injection. This can be easily avoided by switching from exec() to execFile(). Example:

let command: string =
this.modelsimPath +
'vlog -nologo -work ' +
this.modelsimWork +
' "' +
doc.fileName +
'" ' +
this.modelsimArgs; //command to execute
var process: child.ChildProcess = child.exec(
command,

would be safer as:

    var process: child.ChildProcess = child.execFile(
      this.modelsimPath,
      [
        'vlog',
        '-nologo',
        '-work',
        this.modelsimWork,
        doc.fileName,
        this.modelsimArgs,
      ],

Though admittedly this does not seem quite right because it seems like this.modelsimArgs can be an arbitrary Bash command. Ideally it would be specified as a list of strings and then you could do:

    var process: child.ChildProcess = child.execFile(
      this.modelsimPath,
      [
        'vlog',
        '-nologo',
        '-work',
        this.modelsimWork,
        doc.fileName,
      ] + this.modelsimArgs,

Environment (please complete the following information):

  • does not matter

Steps to reproduce

  • based on static analysis

Log
N/A

Expected behavior
In the current implementation, if someone sneaks in something like a doc.fileName this is a Bash command, such as ; exit; or what have you, then that's evidence of a possible Remote Code Execution vulnerability.

Actual behavior
Using execFile() should prevent the sort of vulnerability described.

Additional context
To fix this properly, it seems like some user config options might have to change from string to string[], which is likely a breaking change unless you want to continue to support the insecure version.

@AndrewNolte
Copy link
Contributor

I don't really understand why security is a problem for a vscode extension? On vscode, you have a shell for you own machine anyway?

@AndrewNolte
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants