Powershell: File Explorer context-menu integration fails with directory names with embedded apostrophes (single quotes)

Created on 9 Apr 2018  路  9Comments  路  Source: PowerShell/PowerShell

Just as the current _Windows PowerShell_ File Explorer context-menu integration (with Shift-right-click) is broken with paths with embedded ' chars. , as described here, so is PowerShell Core's.

The following two lines must be revised in accordance with the linked instructions:

https://github.com/PowerShell/PowerShell/blob/77f36498e613037babcc99029ca386e36f3b7b59/assets/Product.wxs#L204

https://github.com/PowerShell/PowerShell/blob/77f36498e613037babcc99029ca386e36f3b7b59/assets/Product.wxs#L212

Environment data

PowerShell Core v6.1.0-preview.1
Area-Maintainers-Build Issue-Bug

Most helpful comment

I'm thinking a -WorkingDirectory parameter makes sense. I'll work on a PR for this.

All 9 comments

@bergmeister do you want to take this?

@SteveL-MSFT I will try to take a look at this but cannot promise anything at the moment (I will be at psconf.eu next week and after that on holiday for 2 weeks so if I cannot fix/investigate it until psconf, then others will need to take a look at it). But it seems @mklement0 has already found the required fix in the linked superuser thread to handle this special case, thanks for the initial investigation.
I am glad people actually use it and find it generally useful :-)

@mklement0 I have tried your suggestion of using \" instead of the ' and various other variations with quotes and it does not work for me. This bug exist also with the native Windows PowerShell integration in Windows as you said. The reason is because %V gets replaced with the actual path and I could not quickly find a way of making the command work because escaping a single quote inside a single quote means that it needs to appear twice. I also tried double quotes, no success but double quotes are not good from a security perspective because folder names can contain $ and therefore you would open up a hole for script injection...
@SteveL-MSFT This would be much simpler if pwsh had a startup path option and then we could also solve the other issue of starting pwsh in the user folder instead of the installation folder.

@bergmeister:

folder names can contain $ and therefore you would open up a hole for script injection...

That's a good point.

I suppose the only way to avoid this to use -File rather than -Command, because the arguments would then be treated as _literals_ by PowerShell, but that would require us to ship a helper script.

@mklement0 I am not sure if -File would solve it because how do you pass the literal string to the function then, I imagine you would run into the same problem. To me it seems to be rather a language problem because adding just one single quote inside a single quote make it invalid syntax. Maybe an expert in batch syntax or Windows could help out?
What do the powershell language experts think @lzybkr or @BrucePay ?

I imagine you would run into the same problem

No, you wouldn't - any argument passed to -File from the outside is a _literal_.

Thus, something like the following would be safe:

powershell.exe -noexit -File  /path/to/helper-script.ps1 "%V"

As an aside: The way that -Command parsing works is really unfortunate, but the decision was made to keep the old behavior.


The alternative is to _document_ the hypothetical vulnerability (I've already added a note to my superuser.com answer) and rely on users being savvy enough to recognize a malicious folder name when they see one.

@mklement0 A sophisticated attack could involve launching an interactive process (a bit like a Ranorex/Selenium test) but by this time the machine is already exploited I guess.
My vote goes for having a -Path option in pwsh because it would also help to fix #5705, which already failed to be solved once.
P.S. I just realised that you're Austrian as well ;)

@bergmeister: Servas ;)

I definitely like the idea of the pwsh CLI having a -Path parameter (though we should think about the specific name, given that Start-Process calls the analogous parameter -WorkingDirectory, for instance; perhaps -WorkingDirectory / -wd?).

Is there an issue for this suggestion yet?

I'm thinking a -WorkingDirectory parameter makes sense. I'll work on a PR for this.

Was this page helpful?
0 / 5 - 0 ratings