In the past Firefox had addressed a "similar" issue with Firefox under Slackware CVE-2009-0068 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0068) when deals with this, so i guess they reconsiderated when this issue appeared to continue using this third party for handling those uncommon protocols

I had to mention that the scripts copyright of the fork used here are from 2006,  was addressed on 2009.

I have used this recent version of xdg-open https://chromium.googlesource.com/chromium/deps/xdg-utils.git/+/741e06fffb562c839641673481e71dbf739dc3fd/scripts/xdg-open and tried to trigger that.
And seems like the original version and this fork still vulnerable for information leakage via bash metachars.
I been doing some tests and the problem is in the transition between Chrome and xdg, a fast and secure way to solve 
this continuing using this modified fork is escape this metachar sequence with an \ character, this will prevent 
to be executed but bash will recieve the data as it is so need to clean inside by a secure way the added character used to escape this secuence.

When bash recieve it just need to clean the \ added before by a secure way to make this transition well and recieve data
as it is and prevent execute any bash metachar outside the sandbox context.
Consideer to report this to the package owner that i guess current responsable of this original package is pelle@debian.org

If need some of the test i did tell me and i will upload them here.

Yes, this variant was observed when I fixed  Issue 711020 . Unfortunately, it's more challenging to fix this one because there are effectively no standards for arbitrary URL handlers, and any restrictions we introduce are harmful for compatibility with third-party applications. On IE, we ultimately had to limit ourselves to writing scary warnings in the documentation and blog post (https://blogs.msdn.microsoft.com/ieinternals/2011/07/13/understanding-protocols/) to warn protocol implementors that they might get dangerous command line arguments from the browser.

On the plus side, unlike mailto, other application protocol handlers will show a warning prompt by default asking if the user would like to invoke the protocol. Unfortunately, the text string passed to the application was removed in a UI-rework in 2015 or 2016, meaning a user can't really make a very well-informed trust decision.

Can you please post a proof of concept link that causes something bad to happen? I can't tell from the report if there is a real bug or a potential bug.

Hey palmer im trying to, but i really have some doubts if that functionality ever worked well, and thats the problem i having rite naw to deploy a full working poc.

For example in the case of Gopher, this is how chrome canonalize the URL when call it externally 

From chrome:
<a href="gopher://localhost:70/encoded url path/">GOPHER</a>

Chrome Call:
gopher://localhost/encoded%20url%20path/

Beyond this point everthing seems normal, but when you add a hash uri schema nothing is encoded.

From chrome:
<a href="gopher://localhost:70/#1\r\n * /">GOPHER</a>

Chrome call:
gopher://localhost/#1
 Descargas/ Documentos/ Escritorio/ Imágenes/ Música/ Plantillas/ Público/ Shared/ VirtualBox VMs/ Vídeos/ private/

The Gopher RFC not define any especial chars in gopher-path so anything can be here, so nothing should be treat specially, included the # hash character, it seems like Chrome canonalize this gopher URI Schema as a http/https uri schema, where hash is not url encoded, if are going to URL encode, URL encode all gopher path included hash because gopher dont understand bout hash uri schema.

By the way, RFC of gopher is very simply to stablish connections as rfc1436 define it.
 Client:          {Opens connection to host at port 70}
 Server:          {Accepts connection but says nothing}
 Client: <CR><LF> {Sends an empty line: Meaning "list what you have"}

It might be exploitable with a fake gopher server that just sniff the gopher path what discloses any OS directory and once this done just reject any shit incomming.

For example the SFTP might be exploited from user/password fields present in the SFTP URI Schema.

Got any specified function to canonalize this protocol or are using another from other protocol instead? XD

btw, xdg-open derivate the call to kde-open, gvfs-open, gnome-open, exo-open im some situations that im still analyzing it (need time)

Its obviously that this third party is deprecated, when xdg-open try to detect de desktop enviroment via detectDE make use of global env vars like $GNOME_DESKTOP_SESSION_ID which are deprecated see this reference https://bugs.freedesktop.org/show_bug.cgi?id=26811 so those places aint reached.

I guess that RCE aint possible here but directories can be leaked as i did in the another issue i reported in some protocols.

Thanks for the report and all the effort you've put into analysing it here. :)

c#3: I'm of the opinion that showing the user the actual command line that will be launched is of very limited benefit. The number of users who would actually be able to parse the string and understand any security implications such as the state of the command line arguments is a tiny fraction of the number of users who would see this very scary looking dialog. It's much more reasonable to give the user a proper app name and make the trust decision on whether or not they want it to launch.

As for the bug here: leaking directory names on the user's file system to an installed app is a little bothersome. But the user would still need to have some malicious app installed that could:

a) be invoked by an external protocol launch
b) receive those directory names and do something with them (send them out for example)

But, if the user has a malicious app installed, it could already spider the entire contents of the user's hard drive if they ran it. The only impact Chrome has here is possibly making launching the bad app easier (but that again supposes the user visits a site with a link that opens the bad app, and then clicks through the prompt that we show).

Based on that, I'm assigning a low impact. I'd actually lean towards marking this as WontFix since it's a fairly involved pathway to actually retrieve any information.

Re c#11: We could have a lively debate about the value and design of the prompt, but this isn't really the right place for that. 

> the user would still need to have some malicious app installed

The app need not be malicious in any way; the application might well dutifully perform its intended purpose ("transmit the arguments on the command line to the address supplied on the command line" as in the case of mailto in  Issue #711020 ) and because of the bash expansion behavior, the behavior results in an information leak. That, of itself, does not presently seem terribly serious.

The more serious concern is that the application might be /vulnerable/ to a command injection attack. There's a long history (going back to the 1990s) of application protocol handlers with argument parsing vulnerabilities that lead to full remote code execution. This represents a significant threat because if/when a vulnerable and popular protocol handler is found, the attacker skates out of Chrome's hardened sandbox with a single click of the mouse. Chrome does not presently have any means to dynamically (akin to SafeBrowsing for downloads) reject protocol handler invocations.

The challenge with the "vulnerable handler" threat, as I mention in #3, is that introducing additional protections here (beyond preventing bash command expansion) represents a direct tradeoff between compatibility and security.

elawrence@, could you suggest some owner for this issue? Or anyone else should take a look at this issue?

+OWNERS for //src/chrome/browser/external_protocol/, as they might know whether we should consider lockdowns in the invoker code, especially on platforms where we're shelling out to xdg-open. 

OK ... this is a complicated one ...

About showing the command line in the prompt: something to keep in mind is that the prompt has a checkbox on it to 'remember choice' or 'always do this' or something. If that is checked once, the prompt will not be shown again, and the next time the command line might be different. So I don't think adding the command line to the prompt will help a huge amount, as the prompt might be hidden.

About disallowing for some schemes: it's hard to say whether we should do this or not without some metrics.

About bash leakage: this doesn't seem like a huge problem, to me anyway, given the low number of Linux users we have.

About compromise in general: this feels like more of a problem. E.g. passing extra info to steam or itunes that tickles a known bug in a particular way. Is there a concrete suggestion of how we could prevent that?

All up I'm more worried about exploits on popular platforms of popular programs that users would typically have used (and hence clicked the 'always do this box') than of exploits on little used platforms of programs that users typically wouldn't have approved already. Is that the right way to be looking at the problem?

RE #16: Indeed, the greatest danger would be exploit of a vulnerability in a popular program that has been preapproved to open without prompting by a large number of users.

I worry that this bug isn't likely to make progress in its current state as we don't have many good options or a known-exploitable combination.

On Linux, where we use xdg-open, we know that the * meta character can be expanded and result in unexpected input. Given that we own both sides (the invoker, and the xdg-invokee) we could look for that known pattern and escape the character accordingly.

To the more general threat ("unencoded URLs may exploit vulnerabilities in external handler applications"), we don't have a path forward that isn't a direct tradeoff between compatibility and security. On Windows, properly escaping quotation marks (unlike what we do atop OpenExternalOnFileThread) would reduce the threat of the most likely vulnerability in handler applications, but it could have some non-zero compatibility impact.

+mgiuca who's owning handlers now and might have some thoughts on this.

the roulette-wheel of unassigned security bugs has identified mgiuca as the best owner for this bug. Can you decide if we need to do anything here and either re-assign to someone else, or close the bug. Thanks!

 Issue 785809  has been merged into this issue.

Adding reporter of the duplicate here.

Perhaps a workable short term step here would be to log UMA data on how often quotation marks appear within calls to protocol handlers? If the number is sufficiently low, we can more confidently take a change here to encode quotation marks, matching Firefox.

From the linked bug:

"Yes I have reported a vulnerability in Unity3D CVE-2017-12939 which was exploitable only through Gooogle Chrome. I will release the exploit details tomorrow."

This bug covers a lot of different issues and is very muddy. The duplicate issue is a specific clear problem which we can address, so I am going to de-duplicate it and respond to comments there.

Most of the discussion in this issue is about the user not knowing what command will be executed when an external program is opened, as discussed in #11, #12 and #16. Let's keep that discussion here and move discussion about escaping to  Issue 785809 . Note that #5 does mention the lack of escaping but I hadn't realised that that's what this was about because it was quite unclear.

I am fixing the escaping issue in  Issue 785809  (by escaping a bunch of illegal URL characters). I can't tell whether this will fix the Gopher example in #5:

<a href="gopher://localhost:70/#1\r\n * /">GOPHER</a>

It will depend on the Gopher client. (Note that very few machines have Gopher installed, even Linux, so I'm not too concerned about it.) We do not escape * (which is a perfectly valid URL character), but we do escape "\r\n" to "%0D%0A". Whether this remains an issue depends on whether the Gopher client decodes "%0D%0A" back into "\r\n". Note that even if we escaped "*" into "%2A", a Gopher client could still decode it back into "*".

In general, we cannot protect against a perfectly valid URL string being passed as an argument to an external command, and then having that command interpret the URL in a way that could harm the user. My goal with  Issue 785809  is to ensure a website can't pass multiple command-line arguments to an external command.

Other than that, we do not plan to show the command-line to the user, as it is technical information that won't really help users decide whether to proceed or not (especially non-technical users, but even technical users will be unlikely to understand whether a particular command string is harmful). Therefore, I am closing this as WontFix.

elawrence: Please let me know if you think there is anything more serious raised above that I've missed. This discussion has touched on a number of unrelated issues so I think it's best to split them out into separate bugs if there are any more.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot