Closed huntr-helper closed 2 years ago
@daffl - let me know your thoughts! π°
@matthewp @justinbmeyer this should get merged i think it looks pritty good to me.
After this PR, the browsers do not exit as expected during the test suite. Prior to the PR during the test battery browsers would exit. I don't know the source of the issue yet but am investigating. @JamieSlome and @Mik317 I would appreciate your help on this.
I am seeing the above problem on MacOS 10.15.7 (my dev machine). Other platforms are as yet untested.
Root cause: Because execFile does not create a subshell, quoting does not work the same way when constructing the command to terminate a process:
Not working:
execFile('osascript', ['-e', '\'tell', 'application', '"Opera"', 'to', 'quit\'']); // this is the result of splitting the original line on spaces
Also not working: `execFile('osascript', ['-e', '\'tell application' "Opera"' to quit\'']);
In each of these cases, the single quote at the beginning and end of the AppleScript snippet is passed to the script interpreter as a literal quote, and it is not accepted. (The error returned is Syntax Error: A unknown token canβt go here
)
Working:
execFile('osascript', ['-e', 'tell application "Opera" to quit']
I have made a PR to address this. No further action is required. Thanks for the security fix!
https://huntr.dev/app/users/Mik317 has fixed the Remote Code Execution vulnerability π¨. Mik317 has been awarded $25 for fixing the vulnerability through the huntr bug bounty program π΅. Think you could fix a vulnerability like this?
Get involved at https://huntr.dev/
Q | A Version Affected | ALL Bug Fix | YES Original Pull Request | https://github.com/418sec/launchpad/pull/1 GitHub Issue URL | https://github.com/bitovi/launchpad/issues/123 Vulnerability README | https://github.com/418sec/huntr/blob/master/bounties/npm/launchpad/1/README.md
User Comments:
π Metadata *
Please enter the direct URL for this bounty on huntr.dev. This is compulsory and will help us process your bounty submission quicker.
Bounty URL: https://www.huntr.dev/app/bounties/open/1-npm-launchpad
βοΈ Description *
The issue arised in multiple locations, so I to validate the type of data the functions were going to use (like the
paths
) and since there were somemulti commands
I didn't use theexecFile
function, which should have had stored many new variables because we wouldn't have been to concatenate and return results that would have been used in a second/third command correlated to the first one executed. In this case I simply made a functionality thatdeletes every quote
from the variable, making impossible threat thevariables concatenated
as commands, but only asarguments
of the specific command.π» Technical Description *
The fix has been applied in 3 different ways inside 3 different files, so I'll comment each one.
name
variable isconcatenated
inside the various commands without being sanitized. Since thename
is inside somesingle-quotes
it would have been useless split the 3 different commands inside 3 differentexecFile
that would have used more resources to store the content of the singular commands that should be concatenated again ... instead I introduced thesafe
function which deletes thequotes
from thename
in order to make it to be only an argument not escapable from quotes.Note I've used the
execFile
function later in this file in the following lines: https://github.com/Mik317/launchpad/blob/master/lib/local/instance.js#L104 and https://github.com/Mik317/launchpad/blob/master/lib/local/instance.js#L110, in order to avoidcommands
could be executed in a dangerous context.execFile
in order to avoid concatenation of other strings containing dangerous characters. Patched with:In this case the first part of the
command
is taken ascommand to execute
(surely a path since thecommand
variable is made through), while the second part are the
arguments
.browser path and filename
weren't checked completely, and even if the execution of malicious code would have been possible only if thedefault browser
of the victim has a badly craftedfilename
, I inserted a check to see if thepath+filename
pointing to the browser is a validpath
. The issue has been fixed through this function:π Proof of Concept (PoC) *
poc.js
file:node poc.js
HACKED
file will we createdπ₯ Proof of Fix (PoF) *
HACKED
file is NOT created anymoreπ User Acceptance Testing (UAT)
It doesn't introduce any error (at least using the module through the PoC I crafted)
Regards, Mik