[DISCUSSION] Allow more URI schemes #10540

@dodexahedron commented on GitHub (Sep 25, 2020):

Well taken.

I tend to be of a mind aligning with the third bullet point above, for a few reasons:

This particular feature is just a convenience to the user, and isn’t likely to be a primary means of interacting with it.
A user who has downloaded, installed, and is using Terminal is significantly less likely to be a novice user who doesn’t understand the repercussions of clicking random links.
The text, as displayed, is the link, is it not? In other words, it’s not like an HTML page, where the displayed text may not match the actual target of the hyperlink.
I highly doubt a malicious actor would go through the effort of having someone open up Terminal in order to carry out their dirty deeds, when there are far simpler ways of getting someone to click a nasty link.
In my opinion, it isn’t Terminal’s responsibility or place to protect a user from themselves any more than any other part of the shell, so, if an action is possible via a click elsewhere, it feels like it should be possible, here, too, to me.

A question/thought, though: If clicked hyperlinks are launched in such a way that UAC will be invoked, regardless of the permissions Terminal was launched with, would that not also be a fairly decent safeguard, leaving all responsibility then up to the user to confirm they want to do something potentially dangerous? Is that behavior possible?

@dodexahedron commented on GitHub (Sep 25, 2020): Well taken. I tend to be of a mind aligning with the third bullet point above, for a few reasons: - This particular feature *is* just a convenience to the user, and isn’t likely to be a primary means of interacting with it. - A user who has downloaded, installed, and is using Terminal is significantly less likely to be a novice user who doesn’t understand the repercussions of clicking random links. - The text, as displayed, *is* the link, is it not? In other words, it’s not like an HTML page, where the displayed text may not match the actual target of the hyperlink. - I *highly* doubt a malicious actor would go through the effort of having someone open up Terminal in order to carry out their dirty deeds, when there are *far* simpler ways of getting someone to click a nasty link. - In my opinion, it isn’t Terminal’s responsibility or place to protect a user from themselves any more than any other part of the shell, so, if an action is possible via a click elsewhere, it feels like it should be possible, here, too, to me. A question/thought, though: If clicked hyperlinks are launched in such a way that UAC will be invoked, regardless of the permissions Terminal was launched with, would that not also be a fairly decent safeguard, leaving all responsibility then up to the user to confirm they want to do something potentially dangerous? Is that behavior possible?

claunia commented

@j4james commented on GitHub (Sep 26, 2020):

I think by default most protocols should warn the user before opening, similar to the way browsers do, with a dialog telling them exactly which application is going to be opened, and the url that triggered the event. We can whitelist a few protocols by default (http being an obvious candidate), but I think that list should be really short. Users can always choose to whitelist individual protocols, but I wouldn't make that too easy for them, otherwise they'll just blindly whitelist everything.

When it comes to the file protocol in particular, we need to be even more careful. I don't think it's good enough to have a blanket whitelist for all file urls. One possibility would be to whitelist particular file extensions in the same way we would whitelist the protocols. So we default to popping up a warning - again letting the user know exactly which application is going to be opened - and then they can always have an option to whitelist trusted file extensions if they really want to.

Another thought I had was to ShellExecute the file urls using an edit verb. So for example if you clicked on a file url for a Python script, ideally we want to allow that to open in an editor, but never allow it to execute. I don't know how feasible that is in practice, though. Does edit guarantee that nothing will every be executed? And are there any file extensions that we would want to support that couldn't be opened that way? That needs to be investigated.

Finally, I should point out that I'm not a security expert, but in my experience security people tend to be way more paranoid than me about stuff like this, and I'm terrified of this functionality. If I were you, I wouldn't want to implement anything that hasn't been signed off by someone senior in Microsoft's security team, especially if we're planning to add hyperlink support to conhost as well, or if Windows Terminals is going to be become the default Windows console one day.

@j4james commented on GitHub (Sep 26, 2020): I think by default most protocols should warn the user before opening, similar to the way browsers do, with a dialog telling them exactly which application is going to be opened, and the url that triggered the event. We can whitelist a few protocols by default (http being an obvious candidate), but I think that list should be really short. Users can always choose to whitelist individual protocols, but I wouldn't make that too easy for them, otherwise they'll just blindly whitelist everything. When it comes to the file protocol in particular, we need to be even more careful. I don't think it's good enough to have a blanket whitelist for all file urls. One possibility would be to whitelist particular file extensions in the same way we would whitelist the protocols. So we default to popping up a warning - again letting the user know exactly which application is going to be opened - and then they can always have an option to whitelist trusted file extensions if they really want to. Another thought I had was to `ShellExecute` the file urls using an `edit` verb. So for example if you clicked on a file url for a Python script, ideally we want to allow that to open in an editor, but never allow it to execute. I don't know how feasible that is in practice, though. Does `edit` guarantee that nothing will every be executed? And are there any file extensions that we would want to support that couldn't be opened that way? That needs to be investigated. Finally, I should point out that I'm not a security expert, but in my experience security people tend to be way more paranoid than me about stuff like this, and I'm terrified of this functionality. If I were you, I wouldn't want to implement anything that hasn't been signed off by someone senior in Microsoft's security team, especially if we're planning to add hyperlink support to conhost as well, or if Windows Terminals is going to be become the default Windows console one day.

claunia commented

@KalleOlaviNiemitalo commented on GitHub (Sep 27, 2020):

I looked for ways to avoid having a list of safe URI schemes in Windows Terminal, but didn't find any.

IAttachmentExecute: Requires a file name.
ASSOCDATA_EDITFLAGS (FTA_OpenIsSafe, FTA_AlwaysUnsafe) or AssocIsDangerous: Most ProgID keys that have a "URL Protocol" value do not have any "EditFlags" value. Some have FTA_Show = 0x00000002 or FTA_SafeForElevation = 0x00200000.
Bind Context String Keys (perhaps an IBindCtx could be provided via SEE_MASK_FLAG_HINST_IS_SITE): Nothing suitable.
STARTF_UNTRUSTEDSOURCE: Could be added via ICreateProcessInputs::AddStartupFlags, but ShellExecuteEx might not create a process, and the URL handler application might not support the flag.

ASSOCSTR_FRIENDLYAPPNAME and IHandlerActivationHost seem to be ways to get the name of the URL handler application, if Windows Terminal wants to display that in the warning.

@KalleOlaviNiemitalo commented on GitHub (Sep 27, 2020): I looked for ways to avoid having a list of safe URI schemes in Windows Terminal, but didn't find any. * [IAttachmentExecute](https://docs.microsoft.com/windows/desktop/api/shobjidl_core/nn-shobjidl_core-iattachmentexecute): Requires a file name. * [ASSOCDATA_EDITFLAGS](https://docs.microsoft.com/windows/win32/api/shlwapi/ne-shlwapi-assocdata) (FTA_OpenIsSafe, FTA_AlwaysUnsafe) or [AssocIsDangerous](https://docs.microsoft.com/windows/win32/api/shlwapi/nf-shlwapi-associsdangerous): Most ProgID keys that have a "URL Protocol" value do not have any "EditFlags" value. Some have FTA_Show = 0x00000002 or FTA_SafeForElevation = 0x00200000. * [Bind Context String Keys](https://docs.microsoft.com/windows/win32/shell/str-constants) (perhaps an IBindCtx could be provided via [SEE_MASK_FLAG_HINST_IS_SITE](https://docs.microsoft.com/windows/win32/api/shellapi/ns-shellapi-shellexecuteinfow#see_mask_flag_hinst_is_site-0x08000000)): Nothing suitable. * [STARTF_UNTRUSTEDSOURCE](https://docs.microsoft.com/windows/win32/api/processthreadsapi/ns-processthreadsapi-startupinfoa#STARTF_UNTRUSTEDSOURCE): Could be added via [ICreateProcessInputs::AddStartupFlags](https://docs.microsoft.com/windows/win32/api/shobjidl_core/nf-shobjidl_core-icreateprocessinputs-addstartupflags), but ShellExecuteEx might not create a process, and the URL handler application might not support the flag. [ASSOCSTR_FRIENDLYAPPNAME](https://docs.microsoft.com/windows/win32/api/shlwapi/ne-shlwapi-assocstr) and [IHandlerActivationHost](https://docs.microsoft.com/windows/win32/api/shobjidl_core/nn-shobjidl_core-ihandleractivationhost) seem to be ways to get the name of the URL handler application, if Windows Terminal wants to display that in the warning.

claunia commented

@DHowett commented on GitHub (Sep 28, 2020):

So, in general I agree with the arguments made on behalf of security here. However, there's one issue that tips me in the other direction:

Given the basic premise that a remote application can't generate meaningful file URIs (it lacks knowledge of the layout of the remote system and any ability to drop files in known places), the concern about an application printing a link to an executable or executable document applies only to local applications.

But then... would such a local application that can produce a path to a malicious executable not itself simply do the bad thing? It's running with the user's integrity level and identity already. It can do far, far worse things than trick the user into clicking a link to another EXE file. It is, or can just directly spawn, an EXE file.

The same holds for URIs handled by applications that act immediately (like a hypothetical ms-settings:reset_system?confirmed=yes&confirm_token=aaaaaa (which doesn't exist, but illustrates the point). Those applications are already potential vectors for attack regardless of who's calling them.

So I guess my question is ... what's the attack, and how does Terminal launching file URIs amplify it?

@DHowett commented on GitHub (Sep 28, 2020): So, in general I agree with the arguments made on behalf of security here. However, there's one issue that tips me in the other direction: Given the basic premise that a remote application can't generate meaningful file URIs (it lacks knowledge of the layout of the remote system and any ability to drop files in known places), the concern about an application printing a link to an executable or executable document applies only to _local_ applications. But then... would such a local application that can produce a path to a malicious executable not itself simply _do the bad thing_? It's running with the user's integrity level and identity already. It can do far, far worse things than trick the user into clicking a link to another EXE file. It _is_, or can just directly spawn, an EXE file. The same holds for URIs handled by applications that act immediately (like a hypothetical `ms-settings:reset_system?confirmed=yes&confirm_token=aaaaaa` (which doesn't exist, but illustrates the point). Those applications are already potential vectors for attack _regardless_ of who's calling them. So I guess my question is ... what's the attack, and how does Terminal launching file URIs amplify it?

claunia commented

@DHowett commented on GitHub (Sep 28, 2020):

If we were talking about terminal automatically fetching (or launching!) URLs as directed by an application, I'd be more concerned...

@DHowett commented on GitHub (Sep 28, 2020): If we were talking about terminal automatically fetching (or launching!) URLs as directed by an application, I'd be more concerned...

claunia commented

@miniksa commented on GitHub (Sep 28, 2020):

I've located an internal contact related to URI handling and reputation. We'll reach out to the experts at Microsoft who have already handled this for other products and get some advice.

@miniksa commented on GitHub (Sep 28, 2020): I've located an internal contact related to URI handling and reputation. We'll reach out to the experts at Microsoft who have already handled this for other products and get some advice.

claunia commented

@j4james commented on GitHub (Sep 28, 2020):

Given the basic premise that a remote application can't generate meaningful file URIs (it lacks knowledge of the layout of the remote system and any ability to drop files in known places),

If it knows you're on a Windows box, it can reasonably assume it'll be able to find a bunch of executables under c:\Windows, or /mnt/c/Windows. It doesn't have to be right 100% of the time.

Also, note that most exploits are a combination of vulnerabilities. You may be thinking this isn't a problem because an attacker can only execute files that are already on the system, but can't drop files there. But there is likely also a developer somewhere thinking they don't have a problem because their vulnerability only allows the attacker to drop files on the system, but not execute them. Combine the two and the user is screwed.

I should also mention that the original proposed hyperlink code would already have allowed a file url to run remote executables using a UNC path to a public SMB share. In my tests, the OS did at least seem to detect that as a remote executable and provide a warning, but I wouldn't want to rely on that being an insurmountable defence. Anything that lets an attacker get closer to an exploit is a bad thing, even if it doesn't seem to go all the way.

@j4james commented on GitHub (Sep 28, 2020): > Given the basic premise that a remote application can't generate meaningful file URIs (it lacks knowledge of the layout of the remote system and any ability to drop files in known places), If it knows you're on a Windows box, it can reasonably assume it'll be able to find a bunch of executables under c:\Windows, or /mnt/c/Windows. It doesn't have to be right 100% of the time. Also, note that most exploits are a combination of vulnerabilities. You may be thinking this isn't a problem because an attacker can only execute files that are already on the system, but can't drop files there. But there is likely also a developer somewhere thinking they don't have a problem because their vulnerability only allows the attacker to drop files on the system, but not execute them. Combine the two and the user is screwed. I should also mention that the original proposed hyperlink code would already have allowed a file url to run remote executables using a UNC path to a public SMB share. In my tests, the OS did at least seem to detect that as a remote executable and provide a warning, but I wouldn't want to rely on that being an insurmountable defence. Anything that lets an attacker get closer to an exploit is a bad thing, even if it doesn't seem to go all the way.

claunia commented

@JasonWThompson commented on GitHub (Dec 11, 2020):

I would love it if the windows terminal supported URIs that point to a specific file resource like sftp. A use case might be to allow someone to script up an alternative form of ls/gci that would output sftp hyperlinks that point to the files listed. One could then ctrl+click to download said file locally rather than having to fire up WinSCP, navigating to the file, and then downloading it to the device.

For that matter if windows terminal supported URIs that pointed to file locations, a future version of Windows terminal could have an option to make the linked item draggable to the desktop. Could you imagine SSH into a host, cd to the log directory, get a listing of files, and then dragging and dropping a listing item to the desktop!? 🤤 Or maybe being able to right click and select, "Open with VS Code" 🤩

I've gone way off topic, but supporting URI/URLs that point to specific file resources would be a dream come true.

@JasonWThompson commented on GitHub (Dec 11, 2020): I would love it if the windows terminal supported URIs that point to a specific file resource like sftp. A use case might be to allow someone to script up an alternative form of ls/gci that would output sftp hyperlinks that point to the files listed. One could then ctrl+click to download said file locally rather than having to fire up WinSCP, navigating to the file, and then downloading it to the device. For that matter if windows terminal supported URIs that pointed to file locations, a future version of Windows terminal could have an option to make the linked item draggable to the desktop. Could you imagine SSH into a host, cd to the log directory, get a listing of files, and then dragging and dropping a listing item to the desktop!? 🤤 Or maybe being able to right click and select, "Open with VS Code" 🤩 I've gone way off topic, but supporting URI/URLs that point to specific file resources would be a dream come true.

claunia commented

@TheXenocide commented on GitHub (May 11, 2021):

I found this while trying to use vscode://file/[path to file]:[line] URIs using ANSI Hyperlinks. It would be very helpful to use already registered system handlers.

I don't see why it needs to be any more secure than a browser (e.g. Are you sure, Choose Application, etc.) but if it was necessary maybe the configuration file can whitelist allowed schemes? (at a minimum, maybe the configuration approach can at least allow a shorter track to allow people to take advantage of them while the rest of the UX is figured out?)

It would also be super handy to have a URI that could enter text as input on the current terminal as I'd love to make my powershell scripts more interactive with less text on the screen. Seems like this could go really well with VCS tooling, powerlines, directory listings (e.g. a hyperlink that change directory to a specific parent) and such.

One of the first things that came to mind to test this with was adding a little config gear to my powerline and making it a hyperlink to vscode://file/$PROFILE or to edit a json config file similarly.

@TheXenocide commented on GitHub (May 11, 2021): I found this while trying to use vscode://file/[path to file]:[line] URIs using ANSI Hyperlinks. It would be very helpful to use already registered system handlers. I don't see why it needs to be any more secure than a browser (e.g. Are you sure, Choose Application, etc.) but if it was necessary maybe the configuration file can whitelist allowed schemes? (at a minimum, maybe the configuration approach can at least allow a shorter track to allow people to take advantage of them while the rest of the UX is figured out?) It would also be super handy to have a URI that could enter text as input on the current terminal as I'd love to make my powershell scripts more interactive with less text on the screen. Seems like this could go really well with VCS tooling, powerlines, directory listings (e.g. a hyperlink that change directory to a specific parent) and such. One of the first things that came to mind to test this with was adding a little config gear to my powerline and making it a hyperlink to `vscode://file/$PROFILE` or to edit a json config file similarly.

claunia commented

@mkanet commented on GitHub (Dec 8, 2022):

I would love to be able to create mailto: and msteams:// clickable links similar to how we open https:// hyperlinks in MS Terminal. I can't tell from the above discussion if we will see this capability or not. Hopefully, there will at least be some way to achieve this through a work-around or official feature.

@mkanet commented on GitHub (Dec 8, 2022): I would love to be able to create **mailto:** and **msteams://** clickable links similar to how we open https:// hyperlinks in MS Terminal. I can't tell from the above discussion if we will see this capability or not. Hopefully, there will at least be _some_ way to achieve this through a work-around or official feature.

claunia commented

@zadjii-msft commented on GitHub (Dec 8, 2022):

note to self: Write-Output "`e]8;;msteams://foo`e\This is a link to teams?`e]8;;`e\" doesn't work, cause we manually block that.

I don't think we ever came to a decision one way or the other. We need to find someone who's an actual expert in this area to give us a bit more feedback. I don't think we're opposed to the idea, but we just don't want to go into this blindly 😄

@zadjii-msft commented on GitHub (Dec 8, 2022): _note to self: ```Write-Output "`e]8;;msteams://foo`e\This is a link to teams?`e]8;;`e\"``` doesn't work, cause we manually block that._ I don't think we ever came to a decision one way or the other. We need to find someone who's an actual expert in this area to give us a bit more feedback. I don't think we're opposed to the idea, but we just don't want to go into this blindly 😄

claunia commented

https://learn.microsoft.com/en-us/windows/win32/shell/known-folders

@Araxeus commented on GitHub (Jan 6, 2023):

Would love to see support for ::{CLSID} and shell: protocols

For example, I have an interactive directory explorer (https://github.com/Araxeus/ls-interactive) and I'm trying to make everything a link
The problem is linking to My Computer - there isn't any valid path to it, only one of the schemes mentioned above

shell:MyComputerFolder

::{20D04FE0-3AEA-1069-A2D8-08002B30309D}

@zadjii-msft I think there shouldn't be security problems with those since they are built in windows

shell: constants:
https://learn.microsoft.com/en-us/windows/win32/shell/search-protocol-crumb#constants-for-common-folders
saved here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\

https://support.microsoft.com/en-us/topic/how-to-redirect-user-shell-folders-to-a-specified-path-by-using-profile-maker-ed6289ae-1f9c-b874-4e8c-20d23ea65b2e

https://docs.rainmeter.net/tips/launching-windows-special-folders/

@Araxeus commented on GitHub (Jan 6, 2023): Would love to see support for [::{CLSID}](https://www.autohotkey.com/docs/v2/misc/CLSID-List.htm) and [`shell:`](https://ss64.com/nt/shell.html) protocols For example, I have an interactive directory explorer (https://github.com/Araxeus/ls-interactive) and I'm trying to make everything a link The problem is linking to `My Computer` - there isn't any valid path to it, only one of the schemes mentioned above ``` shell:MyComputerFolder ``` ``` ::{20D04FE0-3AEA-1069-A2D8-08002B30309D} ``` @zadjii-msft I think there shouldn't be security problems with those since they are built in windows ---- [`shell:`](https://ss64.com/nt/shell.html) constants: https://learn.microsoft.com/en-us/windows/win32/shell/search-protocol-crumb#constants-for-common-folders saved here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions\ https://learn.microsoft.com/en-us/windows/win32/shell/known-folders https://support.microsoft.com/en-us/topic/how-to-redirect-user-shell-folders-to-a-specified-path-by-using-profile-maker-ed6289ae-1f9c-b874-4e8c-20d23ea65b2e https://docs.rainmeter.net/tips/launching-windows-special-folders/

claunia commented

@WasabiFan commented on GitHub (Feb 11, 2023):

Big 👍 here.

If there's uncertainty over which schemes are "safe" to automatically allow, it seems to me a configuration option to enter a list of schemes (or a URL regex) would be an effective stopgap. I have scripts which output vscode:// and similar URLs as mentioned in a comment above and it's ineffective in Terminal.

@WasabiFan commented on GitHub (Feb 11, 2023): Big 👍 here. If there's uncertainty over which schemes are "safe" to automatically allow, it seems to me a configuration option to enter a list of schemes (or a URL regex) would be an effective stopgap. I have scripts which output `vscode://` and similar URLs as mentioned in a comment above and it's ineffective in Terminal.

claunia commented

@mkanet commented on GitHub (Mar 8, 2023):

Maybe some URI's that aren't a security concern can get added first? Who actually decides what can get added and what can't?

@mkanet commented on GitHub (Mar 8, 2023): Maybe some URI's that aren't a security concern can get added first? Who actually decides what can get added and what can't?

claunia commented