Repository navigation
File Explorer context-menu integration fails with directory names with embedded apostrophes (single quotes) #6598
Description
Activity
- changed the title
[-]File Explorer context-menu integration fails with directories with embedded apostrophes (single quotes)[/-][+]File Explorer context-menu integration fails with directory names with embedded apostrophes (single quotes)[/+]on Apr 9, 2018 Christoph Bergmeister (@bergmeister) do you want to take this?
Steve Lee (@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 Michael Klement (@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 :-)Michael Klement (@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%Vgets 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...
Steve Lee (@SteveL-MSFT) This would be much simpler ifpwshhad 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.Christoph Bergmeister (@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
-Filerather than-Command, because the arguments would then be treated as literals by PowerShell, but that would require us to ship a helper script.Michael Klement (@mklement0) I am not sure if
-Filewould 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 Jason Shirk (@lzybkr) or Bruce Payette (@BrucePay) ?I imagine you would run into the same problem
No, you wouldn't - any argument passed to
-Filefrom 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
-Commandparsing 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.
Michael Klement (@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-Pathoption inpwshbecause 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 ;)Christoph Bergmeister (@bergmeister): Servas ;)
I definitely like the idea of the
pwshCLI having a-Pathparameter (though we should think about the specific name, given thatStart-Processcalls the analogous parameter-WorkingDirectory, for instance; perhaps-WorkingDirectory/-wd?).Is there an issue for this suggestion yet?
I'm thinking a
-WorkingDirectoryparameter makes sense. I'll work on a PR for this.Reacted by Michael Klement and Christoph Bergmeister
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:
PowerShell/assets/Product.wxs
Line 204 in 77f3649
PowerShell/assets/Product.wxs
Line 212 in 77f3649
Environment data