1895169 - Don't use MIMEsniffing on local files, only open as HTML or XML if the local file has the appropriate extension

Status: REOPENED

(Core :: Networking: File, enhancement, P3)

Description

[adithyas2k]

Attachment: poc.php

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

Steps to reproduce:

1. Create a file without an extension or with a non-HTML related extension (like .c, .cpp, .php, .msi, .bat, .log, .sql, .sh, .lnk, emoji extensions, etc.).
2. Insert valid HTML and JavaScript code into this file.
3. Open this file in the Firefox browser.
4. The HTML and Javascript code in the file gets executed by the firefox browser.
5. Tested on Windows 10

Actual results:

The HTML and JavaScript code is executed in non-HTML files and files without extensions, deviating from the expected behavior.
Potential Impact: The identified anomaly could potentially facilitate the execution of malicious HTML and JavaScript code encapsulated within files with certain extensions or devoid of an extension, thereby posing security risks.
Exploitation Scenarios:

1. An attacker can upload a nameless file containing malicious HTML and JavaScript code to a reputable website. If a user downloads this nameless file, Firefox will append a random string to its name. If Firefox is set as the default browser, it will be the first option in the menu to open the file. Upon opening, the malicious code in the file will be executed.
2. If user input to a website is saved in log files, a user can send HTML and JavaScript code as input, which will be saved in the log files. If a website administrator opens the log file in Firefox, the HTML and JavaScript code will be executed.

Expected results:

The HTML and JavaScript code in non-HTML files should be rendered as plain text without execution, aligning with the behavior exhibited by Chromium and other Chromium-based browsers. In HTML and HTML-related files, the HTML and JavaScript code should be executed.

Comment 1

[Daniel Veditz [:dveditz]]

A "file extension" is for files; documents from a web server are supposed to use a Content-Type: header to specify the document type. A web server that serves documents without a content-type header—like your testcase—is insecure: the interpretation of the content is at the whims of the connecting user agent (browser).

There has been an attempt to unify browser behavior. See
https://mimesniff.spec.whatwg.org/#rules-for-identifying-an-unknown-mime-type

None of the browsers are doing a great job at implementing it. Inconsistencies are known:
https://wpt.fyi/results/mimesniff/mime-types?label=master&label=experimental&aligned&q=mimesniff

Comment 2

[adithyas2k]

Dear Daniel Veditz,

Thank you for your response. I appreciate your time in reviewing my report. However, I believe there may have been a misunderstanding about the nature of the bug.

The issue I reported is not related to documents served from a web server, but rather to local files being opened in the Firefox browser. Specifically, the bug involves the execution of HTML and JavaScript code inside any local file without an extension or with non-HTML related extensions when the file is opened in the Firefox browser.

This behavior deviates from the standard observed in Chromium and other Chromium-based browsers, where the execution of HTML and JavaScript code is confined to HTML and HTML-related files.

I hope this clarification helps in understanding the issue better. Please let me know if you need any further information.

Best regards, Adithya

Comment 3

[:Gijs (he/him)]

(In reply to adithyas2k from comment #2)

Dear Daniel Veditz,

Thank you for your response. I appreciate your time in reviewing my report. However, I believe there may have been a misunderstanding about the nature of the bug.

The issue I reported is not related to documents served from a web server, but rather to local files being opened in the Firefox browser. Specifically, the bug involves the execution of HTML and JavaScript code inside any local file without an extension or with non-HTML related extensions when the file is opened in the Firefox browser.

In this case, please provide much more precise steps to reproduce. I just tried this with a cpp file and I saw plain text and no script execution.

Also, please explain how an attacker would exploit this.

Comment 4

[adithyas2k]

Dear Gijs,

First of all, I’d like to apologize for the delay in responding to your request. I have been dealing with some health issues over the past few months, which unfortunately prevented me from continuing work on this. I appreciate your patience, and I’m now available to provide further clarification on the reported issue.

Key Detail About the Bug:
The bug occurs when a file containing valid HTML and JavaScript is opened in Firefox, even if the file has a non-HTML extension (like .cpp, .log, .sql, etc.) or no extension at all. If the file starts with valid HTML, Firefox will execute the HTML and JavaScript code.

This behavior contrasts with Chromium-based browsers, where HTML and JavaScript are not executed in files unless the extension explicitly indicates that the file is HTML.

However, text files with the .txt extension are always rendered as plain text in Firefox, as expected, and this issue does not affect .txt files. The bug is primarily relevant to files with other non-HTML extensions or files without extensions.

Steps to Reproduce:
Create a new file with a non-HTML extension (e.g., .cpp, .log, .sql, etc.) or without any extension.

Insert valid HTML and JavaScript at the very start of the file, such as:

html
Copy code
<html>
<body>
<h1>Test</h1>
<script>
alert('JavaScript Executed');
</script>
</body>
</html>
Open the file in Firefox (by dragging it into an open Firefox window or using "Open with Firefox").

Observe the behavior:

If the file starts with valid HTML, the HTML and JavaScript code will execute (e.g., the alert pops up).
Files with the .txt extension are rendered as plain text, and no code execution occurs.
Expected vs Actual Results:
Expected Behavior (as observed in Chromium-based browsers): Files with non-HTML extensions (or no extension) should be rendered as plain text, and no HTML or JavaScript should be executed.

Actual Behavior (in Firefox): HTML and JavaScript are executed if the file starts with valid HTML, even when the file has a non-HTML extension or no extension. This behavior does not apply to .txt files, which render as plain text as expected.

Exploitation Scenarios:
This issue could potentially be exploited in the following ways:

Malicious File Delivery:

An attacker could craft a malicious file with a non-HTML extension or no extension at all, but with valid HTML and JavaScript at the start. If a victim opens this file in Firefox (especially if it is their default application for opening such files), the JavaScript code will execute.
Delivery Methods:
The attacker could send this file via email, file-sharing platforms etc, tricking the victim into opening it.
Alternatively, the victim could download the file from a reputable website (believing it to be a legitimate file like a log or configuration file) and then open it using Firefox as the default application.
Potential Consequences:
Network-based attacks: The malicious JavaScript could be used to establish a connection to an external server controlled by the attacker and send data such as metadata about the victim’s environment (e.g., IP address, browser details).
Exploitation of Firefox vulnerabilities or browser extensions: If Firefox or any installed extensions have known security vulnerabilities, the JavaScript could attempt to exploit them to perform unauthorized actions or escalate privileges.
Server File Upload Exploit:

If an attacker has the ability to upload files to a web server (for example, through a file upload form), they could upload a file with a non-HTML extension (such as .log, .cpp, or .sql) that contains malicious HTML and JavaScript.
If the server admin later opens this file in Firefox (assuming it to be a harmless file), the embedded JavaScript will execute.
Example Exploit: The JavaScript could initiate a network connection to an external server, disclosing information about the admin’s environment. Additionally, it could exploit any browser vulnerabilities or interact with extensions the victim has installed, potentially leading to privilege escalation or other unauthorized actions.
Important Clarification:

I hope this additional clarification helps to explain the nature of the bug and the potential security implications. Please let me know if further information or testing is required.

Best regards,
Adithya

Comment 5

[:Gijs (he/him)]

(In reply to adithyas2k from comment #4)

If an attacker has the ability to upload files to a web server (for example, through a file upload form), they could upload a file with a non-HTML extension (such as .log, .cpp, or .sql) that contains malicious HTML and JavaScript.
If the server admin later opens this file in Firefox (assuming it to be a harmless file), the embedded JavaScript will execute.

But none of those extensions are set up to open with Firefox by default. As a user, you'd have to deliberately force Firefox to open the file rather than the OS default (as you said, by dragging or other more elaborate configuration options).

If I was an attacker and I needed my victim to run my custom HTML, why not just send an HTML file? That would also work if you "just" opened the file, and work in any browser.

It's surprising to me that we sniff arbitrary file content independent of the file extension, so I can ask someone on the networking team why that happens even for file links. But I don't see that it's a security issue.

Comment 6

[adithyas2k]

Dear Gijs,

Thank you for your feedback, and I’d like to provide further clarification based on a real experience I encountered that highlights the issue.

A few months ago, I downloaded a nameless file from a reputable website while browsing in Firefox. As is typical for nameless files, Firefox automatically added a string of random characters as the filename. Since I often use Chrome and had previously opened files without extensions in it without any issues, I expected similar behavior in Firefox, meaning that the file would simply render as plain text.

However, when I opened the file in Firefox, it executed HTML and JavaScript code embedded within it. The JavaScript code performed browser fingerprinting and sent data to a remote server. This was quite unexpected, and had I known that Firefox would execute code in files without extensions, I would have been more cautious.

Why This is a Concern:
While it's true that Firefox isn’t set up to open certain file types (like .cpp, .log, etc.) by default, users can still inadvertently open files without realizing the risk, especially when:

Files are nameless or have misleading extensions:
In cases where the extension doesn’t signal any immediate danger, users (including myself) may assume the file is safe and open it in Firefox, not expecting any code execution.

Firefox’s unique behavior:
In contrast to Chromium-based browsers, which don’t execute HTML/JavaScript in non-HTML files or files without extensions, Firefox’s handling of such files can lead to unexpected script execution. For users who switch between browsers, this difference can be surprising and dangerous.

Exploitation:
This behavior can lead to scenarios where:

Users unknowingly open malicious files:
As in my case, users might download files from trusted sources or websites, assume they are safe, and open them in Firefox without expecting that HTML or JavaScript could be executed.
Reputable websites or file-sharing platforms: Users who download files from these platforms (e.g., log files, nameless files, or files with misleading extensions) might open these files in Firefox, unaware that scripts could run in the background.
The real risk lies in the fact that users may not anticipate this behavior and thus may unintentionally open files that execute malicious code, as I did. This could allow attackers to run JavaScript that interacts with the browser environment, possibly collecting sensitive information or fingerprinting the user’s system.

I hope this personal experience illustrates why this issue may pose a real security risk, especially for users who regularly switch between browsers or download files that are either nameless or have non-HTML extensions. Given the difference in behavior between browsers, it could catch many users off guard.

Please let me know if you’d like additional details or further clarification.

Best regards,
Adithya

Comment 7

[Valentin Gosu [:valentin]]

(In reply to :Gijs (he/him) from comment #5)

It's surprising to me that we sniff arbitrary file content independent of the file extension, so I can ask someone on the networking team why that happens even for file links. But I don't see that it's a security issue.

Since bug 1948543 we no longer sniff the file extension for http/s URLs. For file URLs we still need to do it as file URLs don't have content-type headers, so we rely on extension and sniffing.

I'll deal with aligning our behaviour to the mimesniff spec in bug 1881258.

Comment 8

[Daniel Veditz [:dveditz]]

(In reply to adithyas2k from comment #2)

I believe there may have been a misunderstanding about the nature of the bug. The issue I reported is not related to documents served from a web server, but rather to local files being opened in the Firefox browser.

I assumed the "poc.php" attachment was example server code that generated the attack, not that that file itself should be saved and then opened. Sorry

(In reply to Valentin Gosu [:valentin] (he/him) from comment #7)

Since bug 1948543 we no longer sniff the file extension for http/s URLs. For file URLs we still need to do it as file URLs don't have content-type headers, so we rely on extension and sniffing.

We DO currently treat local files as if they came from a server with a missing content-type header, and apply sniffing. That's historical behavior. This bug is saying Chrome doesn't do that (nor does Safari from my testing) and that's a much safer behavior. I agree: that would be much safer, and even more so for former users of other browsers. In Chrome files will not be "sniffed" as a potentially script-running document, they will only interpret local files as HTML, SVG, or XML if they have an appropriate extension (.html, .htm, .svg, .xml ... ?). I don't know if they do sniffing for image types, but that's not dangerous so we don't have to care in this bug.

Comment 9

[Kershaw Chang [:kershaw]]

Hi Valentin,

What do you think we should do here?

Thanks.

Comment 10

[Valentin Gosu [:valentin]]

Makes sense to try this.
The fix should be quite easy: In nsUnknownDecoder::DetermineContentType instead of calling SniffForHTML we can instead call
nsUnknownDecoder::SniffURI for file URLs.

Comment 11

[adithyas2k]

I also want to add that attackers can use the pre tag in a C file or any other non html file and add some code of that language in it and when it is opened in the firefox browser it will look just like plain text with no code execution, while malicious javascript code runs in the background without the user's knowledge.

Comment 12

[Daniel Veditz [:dveditz]]

This does not qualify for our bug bounty program.