I don't think this has anything to do with SDCH, per-se. To summarize:

1. DCT files are not a "Known" file extension in Chrome and thus are not treated as potentially Dangerous by the Downloads system or Safe Browsing.

2. A DCT file, if opened in Chrome (the extension isn't mapped to Chrome, but the user could manually open it) could execute embedded JavaScript

I don't think there's anything special about DCT here either; you can do the same thing with any arbitrary file type, e.g. ".foo"-- see https://whytls.com/test/foo.htm

As far as I can tell, this vector doesn't net an attacker anything of value; he can run JavaScript from the local file, but (unlike in, say, IE5) that script doesn't have access to anything of significant value. It could interrogate its own URL which would reveal the path to the user's download folder (and thus, likely, their login name) but this doesn't appear especially consequential. If we wanted to close this down, we could require that local files opened be treated as text/plain if they don't have a proper HTML file type, but this would have some compat impact.

vakh please can you triage this safe browsing report.

Hi,

Okay, there's a couple subtleties that I would like to point out to contrast between the foo.foo file example and the .dct file.  When I click on your file link the browser prompts me to download via a saveas file selection pop-up window; whereas with the .sdc file, it automatically gets put in the downloads folder.  

Also, when I navigate directly to the URL in href link (https://whytls.com/test/foo.foo) the browser renders the file as plain text  - it does not get downloaded to my downloads directory.

As for the priviledge escalation w.r.t. loading a local html file verses a remote file, the increased privilege and available actions that the Javascript can perform in the local case is plentiful.  For instance, local file/share access, NetNTLM cred transfers, various protocol handlers that only 'pop' when/if loaded locally, etc., etc.  Of course, this privilege escalation is not what I am reporting on and simply exists (mentioned here only towards providing a PoC).  

To help clarify a valid attack vector of significant threat, take RFD (remote file download; or Drive-by Download). Now of course, an attacker can not control the file extension in this case, however if a victim has enticed a user to visit a malicious page, the Javascript could:

i).   Download the .dct file silently in the background, then
ii).  Load that file, which contains JavaScript that 
iii). Executes/Runs under the context/permissions of a locally loaded file.

Which is something malicious Javascript can't do on it's own if a user visits a malicious page; nor can it do so by leveraging an dictionary file with malicious payloads so long as it's stored/runs within the browser's sandbox.  

Hope that helps,
Charles

I'd like to understand your claim "ii" that an attacker can "Load that file". By what means is an attacker able to load the downloaded file? He could certainly ask the user to open the file by clicking on it and selecting a browser to open it, but I do not see any method by which he can load the file automatically.

Chrome's behavior with regard to downloads of uncommon file types is subtle and confusion is understandable. When the browser is asked to navigate to a given URL, it often does not know a priori whether the result will be a new document in the browser window or something that gets treated as a file download. The determination that the result should be treated as a download is made based on:

1. Whether the <A> tag linking to the target has a HTML5 "download" attribute (indicating that the result should be treated as a download regardless of the browser's ability to render the content)

2. Whether the target resource's HTTP headers specify "Content-Disposition: attachment" (indicating that the result should be treated as a download regardless of the browser's ability to render the content)

3. The MIME type of the target resource, typically specified by the web server in a Content-Type response header; sometimes determined by "sniffing" the bytes of the resource to determine whether it represents a known type. If the type so specified or determined cannot be rendered by the browser, it is treated as a download. As a general rule-of-thumb, browsers do not care about the file extension of the URL (except IE, which uses it as an input into its sniffing algorithm).

In the case of the foo.foo file, the reason it renders in plaintext when you navigate to it is that my server declares the MIME type to be "Content-Type: text/plain"; if it instead specified, for instance, "text/html" the content would be treated as HTML and embedded script would run.

> the browser prompts me to download via a
> saveas file selection pop-up window

This generally is not the case. Do you have the non-default setting "Ask where to save each file before downloading" in chrome://settings/search#downloading enabled? If not, it's also possible that you're encountering a quirk of the ALLOW_ON_USER_GESTURE behavior for some file types, whereby sites you visit regularly can download the type without notice while those you do not get an extra prompt. If the .foo file were moved to the same server as the .DCT file, you would likely see identical behavior.

>For instance, local file/share access, 
>NetNTLM cred transfers, various protocol 
>handlers that only 'pop' when/if loaded locally, etc., etc.

You may find that the level of granted permission is lower than you expect thanks to the handling of same-origin-policy for File:// resources in Chrome. I'm not aware of any mechanism in Chrome for a protocol handler to limit itself to only launching via the File protocol, but I'd be interested to hear which do. 

>dictionary file with malicious payloads so long as it's
>stored/runs within the browser's sandbox.

To be clear here, no matter how you open the .DCT file (via a local file:// URI or via a HTTP url) the file always loads within the browser's sandbox.

Hi,

Not sure why your tone is so aggressive here.  I am only trying to patiently explain this to you.  You have misunderstood a number of things I tried to explain, so I will try better to explain them.  I will try to tackle them one at a time, but I feel as though I am now defending myself, which is not only poor posture to feel given the circumstances; but defending petty side facets in my follow-up comments that are widely known, accepted, practiced in the industry. 

Firstly, I should mention that I placed the foo.foo file on my server, and as expected and as with any other file, the saveas dialogue box pops up (as per my settings in Chrome).  That without a doubt, this behaviour with the .foo file is different that with the .dct file.  

You wrote,
"I'm not aware of any mechanism in Chrome for a protocol handler to limit itself to only launching via the File protocol, but I'd be interested to hear which do." 

Okay, what? With all due respect, your comment(s) are indicative of your confusion.  What I was referring to was not protocol handlers that limit themselves to those launched via the File protocol....as I'm not even sure what that is or if it's possible.  So you're saying something like: "File://PHandler://foobar".  Regardless, this is not what I wrote.  I wrote that some protocol handlers often have limitations based on their origin and/or their use can not be instantiated or act unless from a local origin. Plus, this taken from my list of ways that JavaScript running from a local file has different privileges than those remotely, and has no real relevancy to the issue I reported.     

You wrote: "You may find that the level of granted permission is lower than you expect thanks to the handling of same-origin-policy for File:// resources".
EXACTLY, I AGREE!  Which is my point when I say that Javascript executing from this local origin is dangerous.  

You wrote: "I'd like to understand your claim "ii" that an attacker can "Load that file". By what means is an attacker able to load the downloaded file?"

Are you kidding me?  This should really be triaged by someone who knows how to load a local file via JavaScript.  In fact, that's a great Google query for those who don't know "How to load a local file using JavaScript.

You wrote: "To be clear here, no matter how you open the .DCT file (via a local file:// URI or via a HTTP url) the file always loads within the browser's sandbox."
You have clearly misunderstood this attack and some concepts required to understand the report.  When the browser loads a .dct file via specified in a Get-Dictionary Response Header, the browser stores this in it's sandboxed file architecture (virtual file system); which is night and day different that storing it in the users' download directory. And this was only mentioned in the discussion at the end of the report and has no real bearing on the issue. 

It doesn't matter how the files are marked as 'download', whether it was through MIME, http headers, content sniffing or otherwise, what matters is the behaviour or vector in which they are downloaded. But that's beside the point, again. 

(I don't feel Chrome's behavior with regard to downloads of uncommon file types is subtle or confusing, maybe this should be triaged to someone who doesn't find them confusing.)  

Please don't attack me with snooty commentary just because you don't understand something.  Humility is how anyone learns.

Respectfully,
HM

I apologize if you find my tone aggressive in any way-- I'm curious to understand your report. I'm asking questions because I'm concerned that there are missing details. Perhaps someone else will have a look and clarify whether they see something that I do not.

> (as per my settings in Chrome)

Can you clarify which setting do you have set that results in a prompt for downloading a "foo" file but not a "dct" file? By default, I do not receive prompts before either file downloads. If I enable the "Always ask where" setting, I receive prompts for both file downloads.

> knows how to load a local file via JavaScript.

Would you mind humoring me with a repro page that runs on a web server on the Internet and opens a local file via JavaScript without a user specifically selecting the local file via an INPUT TYPE=FILE? This would be an interesting vulnerability.

> I wrote that some protocol handlers often have limitations 
> based on their origin and/or their use can not be instantiated 
> or act unless from a local origin. 

Would you mind humoring me with an example? 

In IE, this is possible for Asynchronous Pluggable protocols (see https://blogs.msdn.microsoft.com/ieinternals/2011/07/13/understanding-protocols/) but I'm not aware of any mechanism to achieve that in Chrome. 

The *only* exception of which I'm aware is that a HTML document loaded via file:// may use file:// for its subdownloads. This is, as you noted, somewhat interesting because it potentially results in the transmission of NTLM hashes.

>> "You may find that the level of granted permission 
>> is lower than you expect thanks to the handling of 
>> same-origin-policy for File:// resources".
> EXACTLY, I AGREE!  Which is my point when I say that Javascript
> executing from this local origin is dangerous.  

My point is that, in Chrome (unlike IE) the Same-Origin-Policy is *more* restrictive for file:// loaded resources. In Chrome, the origin for file://-loaded resources is unique, blocking access to other files. An attacker running JavaScript from a file://-served HTML file in Chrome has "broken into jail."

+cc: mmenke@, rdsmith@ -- based on some other discussions, I gather that you guys know about SDCH file behavior and handling in Chrome. If I'm wrong, please accept my apologies and feel free to unsubscribe.

elawrence@ -- Thanks for the initial triage.

wildbugs2secureharbors@gmail.com: Thanks for reporting this issue. I apologize for the confusion in this comments.
To be able to triage this issue better, can you please:
1. Confirm that a .DCT file is not opened by a web browser by default?
My research suggests that it double-clicking it typically opens CAD software or Microsoft FoxPro.
2. Share a PoC that demonstrates that running JavaScript locally is dangerous. Lack of a PoC is an important part of being eligible for the bounty.

I'd also like to clarify that automatic download of the file isn't considered dangerous by itself.
For a download to be considered dangerous, it should be launchable with little or no user action, and must harm the user in a demonstrable way.

This doesn't really seem to have anything to do with SDCH.  This is the default behavior when navigating to a MIME type that we don't know how to display.  Unless receiving an SDCH Content-Type for a download indicates somehow it's more likely to be malicious than the exact same file with a binary/octet-stream MIME type, I don't think there's any problem here, at least as far as SDCH is concerned?

Thanks mmenke@

I'm marking this bug as WontFix for now. Please re-open it if you have more information or answers to my questions in #c9. Thanks.

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

For all Download Protection VRP bugs: removing label Restrict-View-Google and adding Restrict-View-SecurityTeam instead.

This wasn't actually a security bug, and wasn't restricted before.