-
Notifications
You must be signed in to change notification settings - Fork 28.4k
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
Allow to opt-out of URL protocol confirmation dialog #95670
Comments
See #95252 which arrived in 1.44.1 |
I have a situation where this is forcing me to answer the question twice. I have an internal tool that generates an HTML page shown in Chrome with links similar to the one I have pasted below. The link points to the line number, column and file that is opened in VSCode when I click on the link from and HTML page that I display through Chrome. Back when I built the tool, I spent quite a while trying to stop Chrome from prompting me each time I open the file but just learned to live with it. Now that this has been added to VSCode, anytime I try to open an html link from Chrome to VSCode I am prompted once by Chrome and then a second time by VSCode. I wish both programs had an option to allow bypass without confirmation but it now appears that links like |
Alternatively, can you add trusted locations option? |
best solution for this case |
Hi just reminding @kieferrm. Consider taking a look at this, please? |
+1 for me on this as well |
+1 |
2 similar comments
+1 |
+1 |
@kieferrm would you accept PR that will disable this popup for files in trusted workspaces or in the whitelisted paths? |
Nice! |
Wondering if there is any updates on this? I experience the same issue on Windows but not on Mac. It is weird & bad UX experience that it asks the question all the time even for whitelisted repo 😞 |
@xitanggg I created very simple PR that removes that prompt for most of the links, which is safe to open. But it was closed without any real review. |
@viperet Thanks for the initiative to submit that PR! That is sad to hear that it wasn't being reviewed. I took a look to catch up on the history and context. Here is the timeline of the events based on my understanding (please correct me if I am wrong):
My understanding is that prior to the introduction of Workspace Trust, code can automatically execute whenever a workspace is opened, therefore the display of the dialog to the user whenever |
@xitanggg to make sure the context is clear, the steps to reproduce the vulnerability (before the fix) were:
Obviously this could be done without manually browsing the URL but by just clicking a link in a web page or via a forced redirect through JavaScript. The fix now prompts the user for a confirmation, showing that something strange is happening. This basically shows the target AFAIK the Workspace Trust does not implement any security feature regarding this. I mean, even though you open a workspace without any trust, visiting a |
@smaury Thanks so much for clarifying the context. It really helps to understand the context and problem now. So the current fix commit 92ff20ac prompts the user before sending the request to Now we are on the same page on the context and problem. It seems for the attack to work, attacker has to send request to @joaomoreno Can you explain why you close that pull request? I don't quite follow what you mean by |
@xitanggg my main concern about a6fa60a is that at a first sight I don't understand if Besides that the fix looks OK to me. This does not 100% prevent access to SMB shares (i.e. if you mounted |
Thanks for your input @smaury! I took a quick look into /**
* Returns a string representing the corresponding file system path of this URI.
* Will handle UNC paths, normalizes windows drive letters to lower-case, and uses the
* platform specific path separator.
*
* The *difference* to `URI#path` is the use of the platform specific separator and the handling
* of UNC paths. See the below sample of a file-uri with an authority (UNC path).
* /
const u = URI.parse('file://server/c$/folder/file.txt')
u.authority === 'server' #The part between the first double slashes and the next slash.
u.path === '/shares/c$/file.txt'
u.fsPath === '\\server\c$\folder\file.txt' So in your example, it would be const u = URI.parse('vscode://file/C:/Users/../Windows/')
u.authority === 'file'
u.fsPath === '\C:\Users\..\Windows\' I don't have the development environment set up for VSCode, but I am able to confirm that is the correct But short answer to your concern: No, it doesn't resolve. It simply returns the part after I like when you bolded might, are you suggesting
To me, it feels like the latter - 2, if the attacker can re-route a local file access @viperet While digging into the source code, I see that a helper function import { hasDriveLetter } from 'vs/base/common/extpath';
if (hasDriveLetter(uri.fsPath)) return false; (One thing I still need to verify is to make sure |
I believe that not resolving the path is a problem since it lets an attacker easily bypass the drive letter check. However, perhaps we can work around it (without implementing full resolution) by checking that there are no double-backslashes anywhere in the path instead of (or on top of) looking for a leading drive letter? I'm assuming that an SMB share must be preceded by a double backslash wherever it occurs to be parsed correctly. |
@xitanggg as @pkaminski stated the problem is in not resolving the path while doing the drive letter check, while resolving it while using it. In this example I browsed I think an easy check is to apply the |
Ah, this is spot on and makes sense now why it needs to be resolved because the path import { hasDriveLetter } from 'vs/base/common/extpath';
const resovledPath = getPathLabel(uri.fsPath, this.environmentMainService);
if (hasDriveLetter(resovledPath)) return false; I have more bandwidth later this week. I can look more into it to confirm and then open up a new pull request so we can close this (unless anyone can get to it earlier, in which case feel free to go ahead to submit the pull request). Thanks @smaury for the pointer and question that get us closer to the solution 🚀🙌 |
I will update my PR with this improved solution today |
main...viperet:main |
I just verify everything works and opened a new PR to get their attention. Also because there is a minor bug in your code, it should be |
So I ended up here with creating my own ps1 script to forward path into VSCode: file Add-Type -AssemblyName System.Web
$path = $args[0] -replace "^vscode://file/", ""
$file = [System.Web.HTTPUtility]::UrlDecode($path)
code --goto $file and replace may be someone will find this usefull =) |
@DifficultNick this is really nice, except that vscode overwrites the registry when it launches |
@mobimaster, unfortunately yes, I reilized it later. I had to make my own file scheme in |
@DifficultNick Thanks, I'm no longer afraid of closing vscode. For anyone else who wants to use this workaround: create C:\Windows\vsc.ps1:
create and run vscode2.reg:
then use vscode2 in your links:
|
We discussed this in the team and #194405 is the proposed solution: the dialog provides a checkbox for "Do not ask again" which will update a setting to control whether protocol links cause a confirmation dialog or not. Given this new setting that allows to opt-out of the confirmation, we decided to:
It is worth mentioning that the changes linked in GHSA-mmfh-4pv3-39hr is the definitive fix for the MSRC case around disclosure of NTLM hashes when malicious UNC paths are opened. #194405 does not change anything around the solutions we implemented for that attack. |
The change is available from our insiders build. You can give our preview releases a try from: https://code.visualstudio.com/insiders/ |
Is there any way to open files by URL without confirmation?
It starts from 1.44 version and has no "Always open" checkbox.
When you need to open a lot of files with URL its not comfortable to click "Yes" every time.
Steps to Reproduce:
Does this issue occur when all extensions are disabled?: Yes
The text was updated successfully, but these errors were encountered: