Summary from the PDF:

While parsing the response from the web servers, Chrome looks for a filename in the Content-Disposition header. If there is no filename there then the filename will be taken from the URL. That function looking for the last occurrence of the “/” or “\\” (for IE) until the occurrence of “;”.

<a 
href="https://media.licdn.com/media/AAEAAQAw.jpg/new_name.hta;aaaa" download="will_not_be_selected_as_file_name.jpg">press here</a>

------------
It's not clear to me how this represents a SOP-bypass; it's more clearly a technique to abuse servers that host user-submitted content into serving files that may be interpreted as a different type after being committed to disk via the download manager.

The demonstration video at http://92.222.208.246/webkit.mp4 is helpful.

The video shows that Chrome's behavior of inferring the filename using DoExtractFileName can be used to set the filename if a victim server is willing to serve a file with attacker-controlled text after the "real" filename. (Note: There are real servers that do have this behavior).

The claimed bypass of SOP is very limited in scope; what they're saying is that they are not able to set the filename via <a DOWNLOAD="name.ext"> and believe that this is a same-origin-policy gated limitation. That is true in Firefox, but  issue 608669  suggests that we don't presently have that protection. 

When performing the repro, I do see the Safe Browsing properly call out to https://sb-ssl.google.com/safebrowsing/clientreport/download with the file (so this isn't a Safe Browsing bypass) but I expect that the service would be considering the victim site as the origin; sites that host user-submitted content on the first party domain (not a best practice) could have their positive reputation used for attribution on a malicious file.

Thanks for reporting this.

elawrence and I have been discussing it, and he points out that it is the same underlying problem as with  issue 608669 , although the described attacks are quite different. The proposed remediation on that is to prevent cross-origin <a download> references from working. That seems to mostly mitigate this attack also, although ultimately I don't think there is anything that 100% solves this problem from the client. Accordingly, I am marking this as a duplicate of the existing bug.

Your suggesting of appending an extension based on MIME-type is interesting, but would be limited by the fact that MIME-types are not always correct or useful (e.g. octet-stream).

Hi, thanks for your quick response.
We can’t access the  issue 608669  to comment about the similarity of the issue, moreover the issue is not only with the <a download> case it is more than that.
 
When the server will not provide the filename via content-disposition, it is possible to change the filename using the url part as in the code DoExtractFileName we demonstrate. For example take a look at the bug we found at Facebook:
 
https://www.youtube.com/watch?v=gICzdhcaDs8
 
 
To make that work with used the same technique, we saw that server doesn’t return filename in the content-disposition so the name will be taken from the URL, and using the /name.extenstion; we where able to change the file to the format we needed to execute the code.

Part of the bug was possible due to the URL manipulation bug we are discussing here.
 
About the suggestion:
 
Your suggesting of appending an extension based on MIME-type is interesting, but would be limited by the fact that MIME-types are not always correct or useful (e.g. octet-stream).
 
We agree that it will be limited because of the octet-stream and so, but in that situation you can just remove the extension.
 
Also we would like to open a CVE on the issue, is there any?
We'll appreciate on getting a credit bug for the time we spend to investigate this bug and all the code we reviewed :) 
 
Thanks in advance,
Dikla Barda, Roman Zaikin & Oded Vanunu

 Issue #608669  utilizes the same mechanism to set the suggested filename.

As noted in your demo video, "Attack relies on the assumption that users will trust a link with Facebook domain". In this case, the domain is Facebook's domain for untrusted user content, FbCdn.com. The attacker gains little else of interest beyond possible trust from the user (e.g. HTA files downloaded by this mechanism go through the normal Download gauntlet with Safe Browsing evaluation, he can already send HTA files from any website he controls, etc). Notably, the attacker does not get the ability to execute script in the victim domain, because the affected codepath concerns only Downloads; the server-supplied MIME type is utilized when rendering content in non-download scenarios. In general, hosting user-supplied content is a risky practice and sites doing so must take appropriate precautions to prevent the hosting of malicious files. For instance, many image upload sites will reencode images to prevent steganography or other smuggling attacks.

As your report concerns a web application vulnerability in Facebook, have you reported this vulnerability to them under their vulnerability reporting program?

You've identified two interesting behaviors with regard to Facebook's CDN site:

   1. FbCdn is willing to serve any file from an existing path appended with arbitrary data in the path component. This allows the attacker to specify the filename and extension suggested to the user.

   2. FbCdn URLs, if appended with dl=1, will send a Content-Disposition: attachment header with no filename parameter. This forces the browser to choose a default filename not supplied by the origin.

The proposal in 608669 is to disallow the DOWNLOAD attribute on cross-origin targets; this will *generally* prevent attackers from inducing download of files of browser-renderable types (e.g. HTML, JPEG, etc) because clicking on the <A> will result in a regular navigation rather than a file download. However, this proposal would not be an effective mitigation in the FbCdn case because Facebook exposes the dl=1 parameter that allows the attacking site to request Download semantics for a resource.

Hi,
 
 
We have reported the issue to Facebook, and they are currently working on a patch.
 
We intend to write a blog post about our findings and we would like to address the webkit bug we disclosed to you in it. We would appreciate your input on this matter. We plan to explain the following:
 
We found that by using the DOWNLOAD attribute at anchor HTML tag we can bypass the same origin policy and force the victim server to download a file with a controlled file name.
Changing the file name and extension is possible due to Chrome’s behavior of inferring the filename using DoExtractFileName, if a victim server is willing to serve a file with the attacker-controlled text after the "real" filename using /filename.extension; as mentioned in  DoExtractFileName.
 
This technique was demonstrated in the LinkedIn bug and HTML anchor download tag POC.
 
Do you have any reservations about what we have written above?
We would be happy to receive any comments you may have about the subject.

thanks, Oded

This vector, while interesting, does not "bypass same-origin-policy", a term of art with specific meaning in the field of web security. Saying that it "circumvents an origin restriction" would be more accurate, insofar as there is a specific origin-related restriction which is circumvented. 

I might not say "force the victim server" insofar as this vector doesn't really "force" the server to do anything. 

thanks for your feedback, is there any CVE number on this issue? 
if not we would like to issue one.

thanks again, Oded

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