Closed Bug 1548207 Opened 6 years ago Closed 5 years ago

text/plain responses with invalid characters are sniffed to binary and downloaded, vector for reflection file download attack

Categories

(Core :: Networking: HTTP, defect, P2)

Product:
Core
Component:
Networking: HTTP
Version:
66 Branch
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: almog3y, Assigned: mayhemer)

Details

(Whiteboard: [necko-triaged])

Attachments

(2 files)

Screenshots and index.php server side code
294.69 KB, application/x-zip-compressed
Details
utf8.png
11.72 KB, image/png
Details

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

Steps to reproduce:

The attached file contains a simple PHP server side code that echoes the name parameter to the page. (index.php)
In addition, the server response contains the following header: Content-Type: text/plain.

The following link echoes the name "Almog" to the index page:
http://example.com/index.php?name=Almog

  • Request and response from the server (bug1.png)
  • Firefox's rendering (bug2.png)

If we add a %01 character to the name parameter, Firefox downloads the response and names the file 'q7HhuqWo':
http://example.com/index.php?name=%01Almog

  • Request and response from the servers (bug3.png)
  • Firefox downloads the page content to the user’s workstation (bug4.png)
  • The downloaded file content (bug5.png)

WHAT WE CAN DO WITH THIS BUG?
Attackers can use this bug for Reflected File download attack.
Reflected File Download is a known attack vector which combines URL path segments and responses that reflect the user request content. With a successful attack, attackers can gain complete control over a victim’s machine by virtually downloading a file from a trusted domain.

The following screenshots show a full attack scenario using this bug.

  1. The attacker crafts a link embedded with the following malicious content which reflected to the response: %02||calc.exe||
    http://example.com/index.php/UpdateFromExample.bat?name=%02||calc.exe||

  2. The following screenshot shows the server's request and response with the reflected 'name' payload. (attack1.png)

  3. The attacker uses phishing methods to lure a victim to access the malicious link. When the victim accesses the link, the browser asks him to download a BAT file. (attack2.png)

  4. The victim runs the downloaded BAT file, due to the fact it was downloaded from a trusted domain, which runs OS commands. Just for the POC, a calculator is opened. (attack3.png)

  5. The following shows the downloaded file content. (attack4.png)

Actual results:

It seems that Firefox automatically downloads files that contain reflected parameters with characters such as %00,%01,%02-%08 when the server's response contains the Content-Type: text/plain header without charset or charset=ISO-XXXX.

Expected results:

Firefox should render the encoded ASCII characters.

Hi all,

Are there any updates about this issue?

Best regards,
Almog Cygel

If a user runs an executable they've run an executable -- if you can convince them to do that and you're not actually trustworthy how can Firefox protect them from that?

Hi Daniel,

Thank you for your response.

Currently, Mozilla Firefox does not render the icon of the following characters (%00-%08), causing the browser to download the response content as a file, instead of presenting it as should happen in content type text/plain. In order to protect the users from this behavior, Firefox should render the icon of these characters (%00-%08) instead of downloading it as a file. Without this behavior, the malicious content will not be downloaded to the victim's workstation, which mitigates this issue completely.

In addition to the mentioned above please let me emphasize some important points about this vulnerability:

  1. Firefox is a commonly used browser. This bug can be used by attackers in order to spread malware such as Trojans, ransomware, RAT, etc using Mozilla's product. It's not the responsibility of the web servers' configuration, it's Mozilla Firefox's behavior.

  2. The user interaction is not the case here, attackers are able to craft malicious URL's which can allow them to bypass the browser's sandbox and change the attack scope from the Firefox browser to the victim's workstation.

  3. The "Content-Type: text/plain" response header is a very commonly used due to the fact that it simply prints all reflected characters to the page and developers use it as a prevention of Cross-site-scripting (XSS) attacks. Therefore, many sites that use this header to protect their users, expose them to a major security risk which can lead to full control over the victims' workstations since Firefox does not present the page content, it downloads it.

  4. Attackers have full control of the downloaded malicious file extension and content. Not only a BAT file can be downloaded also JS, EXE, HTML, HTA, PS, sh, etc.

Please reconsider since it's a serious security issue.

Thanks,
Almog Cygel

Hi Daniel,

Are there any updates about this issue?

Best regards,
Almog Cygel

The problem with text/plain is that it's a default setting and used on many files that are not. It looks like we're detecting the unprintable control characters (there is no "icon" that can be displayed for those) and "sniffing" it as a binary file, which triggers the download logic.

I'm not sure this is wrong, or what legit sites would break if we stop doing this.

Attached image utf8.png —

Hi Daniel,

Thanks for the response.

When the charset of the text/plain header is set to UTF-8, the "icons" of the problematic characters (%00-%08) are shown and the page content is not downloaded as you can see in the following screenshot:
http://example.com/index.php?name=Almog%00%01%02%03%04%05%06%07%08 (utf8.png).

In order to solve this problem, Firefox should print the "icons" of the problematic characters (%00-%08) no matter of the text/plain charset attribute.
In addition, the goal of text/plain is to show the text as is so this behavior is not relevant to this header purpose. Regarding legit sites behavior, the fact that Firefox downloads the page content when using unprintable characters harms legit sites which use the text/plain header.

Thanks

Hi Daniel,

Are there any updates about this issue?

Best regards,
Almog Cygel

Hi all,

It seems that this issue won't be fixed and I would like to publish this vulnerability to the community in order to be aware of this firefox's behavior.

I still think this is a major issue that can harm firefox users due to the following reasons:

• With a successful attack, an attacker can get full control of firefox users' workstations.
• It is firefox's behavior, not a server misconfiguration issue.
• The header Content-Type: text/plain is a very commonly used header.
• The header Content-Type: text/plain is used in order to display content, not to download it.
• The attacker can change the type of the downloaded content, so he can use HTA file that firefox does not warn about a dangerous file.

Thanks.

Flags: needinfo?(tgrabowski)

It doesn't seem like we are going to be changing this behavior now. The scenario described is similar to any other form of phishing that rely on users downloading malicious content from the Internet. Plus the proposed solution might potentially break legitimate websites.

Flags: needinfo?(tgrabowski)

Looks like we're "sniffing" the text/plain response (common misconfiguration), seeing the non-printable control characters and assuming it's a binary file, which then triggers a download.

One potential fix is to stop "sniffing" and just show the text/plain document. Some binary documents will end up displayed rather than downloaded (we added sniffing for a reason) but maybe few enough that we could make people take steps to manually save the files these days.

Other than that nothing seems "wrong" here -- a website allowed un-sanitized input into a file they generated, the user downloaded it, then the user ran it.

Group: firefox-core-security → network-core-security
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking: HTTP
Ever confirmed: true
Product: Firefox → Core

Hi guys, thanks for the response.

If a website wants that a user will download a binary file, it will use an appropriate header, such as application/octet-stream and not the text/plain header. As RFC2046 (http://www.rfc-editor.org/rfc/rfc2046.txt) says "The "octet-stream" subtype is used to indicate that a body contains arbitrary binary data".
As you said, a simple solution is to stop "sniffing" te text/plain response with the ISO-XXXX charset and only presents the non-printable control characters as default symbols.

Would you find this as a suitable solution?

Thanks

Hi all,

Are there any updates about this issue?

Thanks

I see this as a P2. I want to find the exact place where we do the sniffing and change the content type. If that is an old compatibility hack, we can consider removing it.

Assignee: nobody → honzab.moz
Priority: -- → P2
Summary: An issue with Firefox's behavior for text responses → text/plain responses with invalid characters are sniffed to binary and downloaded, vector for reflection file download attack
Whiteboard: [necko-triaged]

Happens at nsUnknownDecoder::LastDitchSniff called from nsBinaryDetector::DetermineContentType when the type is one of text/plain possible mime (sub)types. First introduced in bug 389677, updated in bug 394647, 12 years ago.

bz, do you have any data (or opinion) if we can remove this server bug workaround now?

Flags: needinfo?(bzbarsky)

I really doubt it. First of all, it was a very common server misconfiguration for a long time to send any unknown files as text/plain. The failure mode was then that a user would click on, say, a .rar file and end up with a screenful of garbage, and a potential renderer hang attempting to render tens of megabytes of very broken "text". That is why the sniffing behavior was added.

In terms of making behavior changes here, I think there are the following considerations:

  1. All browsers interoperably handle such "broken" text/plain by downloading. I tested https://web.mit.edu/bzbarsky/www/testcases/mime-handling/0-byte-in-text-plain.txt and https://web.mit.edu/bzbarsky/www/testcases/mime-handling/1-byte-in-text-plain.txt (which send data that has a byte with value 0 and a byte with value 1 respectively) just now in Firefox, Safari, and Chrome, and all three have this behavior.

  2. The web platform specs in fact require this behavior (again, because it's needed for web compat in practice and everyone implements it). See https://html.spec.whatwg.org/multipage/browsing-the-web.html#process-a-navigate-response which calls into https://mimesniff.spec.whatwg.org/#computed-mime-type in step 4. That runs https://mimesniff.spec.whatwg.org/#mime-type-sniffing-algorithm which in step 3 does the "is this text or binary?" check we're talking about here. The "check for apache bug" flag gets set when computing the "supplied type" (see https://mimesniff.spec.whatwg.org/#supplied-mime-type-detection-algorithm step 2.1.2).

So anyone who wants to change the behavior here should probably gather data on how often this codepath is used in practice, then use that data to convince other browsers and the spec to change. Otherwise they're just creating compat issues for users and authors.

I'm open to suggestions for mitigating the reflection attack issue, but those suggestions should probably be raised as spec issues, given the well-specified behavior and existing browser interop.

Flags: needinfo?(bzbarsky)

Boris, thanks for your exhausting answer!

From my POV, this is a WONTFIX then and I think it would be better to open this bug to allow public discussion. Otherwise, this should be filed again as a spec issue, probably against whatwg, with all the details of the attack and its possible severity again.

Daniel, do you agree to open this bug based on the above two or three comments?

Flags: needinfo?(dveditz)
Group: network-core-security
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(dveditz)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: