1440622 - "Content-disposition: attachment" files opened in browser (not saved) can read other files in the temp directory

Status: RESOLVED FIXED

(Core :: DOM: Security, defect, P3)

Description

[ih3artPHP]

Attachment: firefox-file-download-sync.php

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36

Steps to reproduce:

I believe I have found a security vulnerability in Firefox which could allow a remote attacker to steal files created by applications (including Firefox itself) from the local filesystem. Exploitation is dependent on certain conditions, and the impact will vary based on the victim user's environment.

As described here https://developer.mozilla.org/en-US/docs/Same-origin_policy_for_file:_URIs Firefox allows file:/// protocol URIs to share the Same Origin Policy for files in the same directory and all sub-directories. When a server returns a HTML file with the content disposition attachment header, users are offered the option to save the file or open it within Firefox. If the user chooses "open", the html file is saved to a temporary directory and opened in Firefox (if Firefox is the default web browser). If an attacker sends a HTML file containing JavaScript code, it would be possible for the script to read any files within the temporary directory. On Windows, the folder the file is saved within is, by default, a temporary folder ("%LOCALAPPDATA%\Temp") used by all system applications to store a veriety of documents, configuration files, and resources. In Linux, the temporary folder was specific to Mozilla Firefox and would therefore only expose a limited number of files created by Firefox.

The only limitation is that the Firefox same origin policy does not allow file:/// URIs to list the contents of directories by default. Therefore, to read a file, an attacker would need to be able to guess the name of it or bruteforce it. However, I have found a number of techniques in Windows Firefox installations which would allow an attacker's script to quickly and reliably determine the names of files in the temporary folder.

* Clipboardcache: When a large amount of text is copied within Firefox (over 500kb), a clipboardcache file is created in the same "%LOCALAPPDATA%\Temp" directory containing the contents of the clipboard. These files do not seem to be deleted and can therefore be directly retrieved by name. (Note on Linux these files are stored in a different parent directory to the opened files and could therefore not be stolen)

* Windows Short Names: Firefox will also open local file:/// URIs using Windows short names, vastly reducing the number of characters which need to be guessed. If this was combined with a targeted wordlist of filenames (for example, company names or dates which may commonly form the start of a filename) the chances of a successful attack could be increased.

* If another application stores files with predictable names in the Windows temporary directory these can be stolen too. Again, this does not affect Linux as the temporary files were stored within a Mozilla specific directory.

This could also be exploited if the file is downloaded/saved by the user and later opened (for example, in the Downloads directory) however this requires more interaction from the victim.

I have created a proof of concept file to demonstrate this issue. It is attached to the bug as a PHP file, only so it could be hosted on a server to set the content disposition header. It has been designed to work with Windows only (due to the limited impact in Linux systems) and demonstrates both the clipboard cache attack (if a large amount of text has recently been copied) and the short name download attack, using a wordlist of 10 short names of PDF files (it will be necessary to "open" the linked PDF file in the same browsing session, or download the file to the same directory that the HTML file is saved to). Instructions are within the POC file.

Note: I would ask that this poc is removed before public disclosure, or at least allow me to upload a modified version instead.

I think to remediate this issue, the best way would be to segregate files opened from the Internet into separate directories, preventing access between them. This is assuming that there is a need to continue to allow SOP interaction between file:/// URIs; although, I should note, this did not appear to be allowed in any other major browser.

I hope I am not highlighting something extremely obvious here, or something that is already known. I realised that a clipboardcache file in my temporary folder actually contained some sensitive data, and I think that could arguably be an issue in itself. If anything is not clear please feel free to contact me.


Actual results:

HTML files were opened in the temp directory, and other potentially sensitive files could be accessed by scripts within the document.


Expected results:

Files opened by the browser should be segregated from temporary files created by other processes, and during the same browser session. This would prevent malicious scripts from accessing sensitive files created by Firefox or other programs.

Comment 1

[:Gijs (he/him)]

The clipboard cache file removal has a WIP patch in bug 335545 that seems to have gotten lost. I've pinged Rob.

The other stuff is more or less known and covered by bug 803143, I believe. I'll leave it up to the rest of the security team to decide what to do with this bug.

Comment 2

[ih3artPHP]

I have just read 803143 and just want to make some distinctions. What is described in 803143 is known behavior and I understand that there are legitimate reasons to allow file:// protocol documents to access files in the same directory. The security issue I am reporting is that when an HTML file is presented for download, clicking "open" in the dialog box causes Firefox to open the file in the temp directory, which is shared by Firefox and other processes. Any scripts in the HTML file could therefore access files created by both Firefox and other programs, as long as they are also created within the Windows temp directory.

Mine, for example, opens in C:\Users\adam\AppData\Local\Temp which contains other files "opened" in Firefox, such as PDFs. There could also be other sensitive files in here saved by other programs, depending on what is installed on the user's system. As an example, in a sub-directory of the temp directory I have files that I have copied from my host to VMs in VMWare.

The risk is slightly increased because Firefox also opens files when the Windows 8.3 shortname is specified, as demonstrated in the PoC attachment.

Sorry if this wasn't clear in the original report.

Comment 3

[Daniel Veditz [:dveditz]]

I agree this is different-enough from bug 803143 to warrant a separate bug. We could easily fix this separately by saving these files into a sub-directory of %temp%.

We've been talking about tightening up our behavior generally to match Chrome. We were the first to deviate from historical "all file: is the same origin" behavior and at the time had to be a little more conservative. If we fix bug 803143 then that would be another way to fix this one.

Comment 4

[ih3artPHP]

Creating a sub-directory would be the easiest fix; this is actually the behaviour I saw on Linux, where every Firefox temporary file was created in /tmp/mozilla_user.

However, the only thing to note on this approach is that HTML files opened in Firefox could also access other files that have been opened during the same browsing session. This is demonstrated in my PoC, where a PDF file which has also been opened in Firefox can be accessed by the malicious JavaScript.

My suggestion would be to isolate temp files into a Mozilla directory, and then further segregate opened files by creating a new temporary sub-directory for each opened file.

Comment 6

[Daniel Veditz [:dveditz]]

fixed by bug 1500453