1556711 - Content-Disposition Pollution by filename of multipart/form-data (RFC specification error)

Status: RESOLVED FIXED

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

Description

To Whom It May Concern

I found security issue &
(maybe) Specifications different from RFC.

I think this problem is minor.

Overview

When sending a specially-crafted file using Firefox,
there is a problem that Content-Disposition is rewritten.
I was able to confirm in multiple web frameworks.

The conditions are as follows.

• Use multipart/form-data
• Include files containing the characters \"; (or "; ) in <input type="file">
• Use a web application framework that has problems with parsing logic.

At present, we surveyed five web frameworks with a star number of 5,000 or more on Github,
and confirmed that Content-Disposition was polluted in three frameworks.

• Spring (Java)
• Ktor (Kotlin)
• Ruby on Rails (Ruby)

I have submitted reports for these frameworks.

Here is a fix example of Spring.
https://github.com/spring-projects/spring-framework/commit/4f05da7fed7e55d0744a91e4ac384d8f5df6e665

Cause and details

When sending files in multipart/form-data format,
many browsers (Chrome, Opera, Safari etc..) URL encode the attachment file name before sending.

On the other hand, firefox does escape processing.
(Windows can not specify the character " in a file. please try Mac or Linux.)

input_file_name: hoge".txt
chrome: hoge%22.txt
firefox: hoge\".txt

sending a PoC request causes the parser to parse incorrectly.

Content-Disposition parser logic (overview):
Split by ";"
Separation of key-value based on the position of "="
Create key=value, key="value" pairs
Generate Content-Disposition

Thus, PoC may be parsed incorrectly by some applications.

RFC 6266

The following was described in RFC 6266
https://tools.ietf.org/html/rfc6266#appendix-D

Avoid including the "\" character in the quoted-string form of the
filename parameter, as escaping is not implemented by some user
agents, and "\" can be considered an illegal path character.

Please judge because it is unclear how important the appendix.

The reason for judging "problem is minor"

This is because the conditions under which this problem occurs complex.
I think that there are few cases in which the value entered by another person enters file_name.

However, in the framework I found, I found a problem that I could change the name parameter.
If this is possible, it will be an attack that will contaminate other fields with the contents of the file.

Reproduction Procedure (used Spring pattern)

1. Create multipart/form-data form.

<form action="localhost:8080/file/upload" method="POST" enctype="multipart/form-data">
  <input type="file" name="file">
  <input type="submit">
</form>

2. Run spring or other insecure App.

example. (sorry, it's dirty code.)
https://github.com/motoyasu-saburi/spring-test/blob/master/src/main/java/bizreach/com/parampoisoning/FormController.java

3. Send file with Firefox.

Create a file with the following name(PoC):

(Spring PoC Example)

example"; name=hoge; size=123456; dummy=.txt

(Rails PoC example)

\"; name=other_field_name; dummy=.txt

"; is the important part.
and, Send this file using Firefox from the form.

4. Content-Disposition property is polluted.

Please App Debug, and Look at the Content-Disposition parameter.
(Or check the parameters of the field.)

Comment 1

[:Gijs (he/him)]

Anne (feel free to redirect needinfo), do any of the HTML/DOM/Fetch specs cover any of this? I found https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#multipart-form-data but that only says

File names included in the generated multipart/form-data resource (as part of file fields) must use the character encoding selected above, though the precise name may be approximated if necessary (e.g. newlines could be removed from file names, quotes could be changed to "%22", and characters not expressible in the selected character encoding could be replaced by other characters).

Which is... not very specific about what must/should happen - but perhaps I'm looking in the wrong place.

Comment 2

[motoyasu saburi]

Thank you for reply!

and The target RFC was wrong, I'm sorry.

Apparently back slash is erased automatically, so I will supplement it.

Include files containing the characters "; (or "; ) in <input type="file">
Include files containing the characters "; (or {BACK_SLASH}"; ) in <input type="file">

firefox: hoge".txt
firefox: hoge{BACK_SLACH}".txt

Avoid including the "" character in the quoted-string form of the filename parameter, as escaping is not implemented by some user agents, and "" can be considered an illegal path character.
Avoid including the "{BACK_SLASH}" character in the quoted-string form of the filename parameter, as escaping is not implemented by some user agents, and "{BACK_SLASH}" can be considered an illegal path character.

(Rails PoC example)
"; name=other_field_name; dummy=.txt
{BACK_SLASH}"; name=other_field_name; dummy=.txt

Comment 3

[Anne (:annevk)]

https://github.com/whatwg/html/issues/3223 and https://github.com/whatwg/html/pull/3276 track improvements here. We do need to define multipart/form-data anew. And what's blocking that is mostly someone doing the work of investigating, writing tests, and writing a processing model.

Comment 4

[Nhi Nguyen (:nhi)]

sending to :mconca for prioritization

Comment 5

[Mike Conca [:mconca]]

Based on the narrow set of conditions under which this occurs (see great original submission in comment 0) and :dveditz classifying this bug as a sec-other, I'm saying this is P3. Keep it in the backlog of things we need to eventually address (particularly if someone else gets to the issues :annevk mentions in comment 3).

Comment 6

[Daniel Veditz [:dveditz]]

Does not meet the bounty criteria

Comment 7

[motoyasu saburi]

Additional Information:

(Ruby on Rails) Content-Disposition Pollution by file name of multipart/form-data.
This allows attacker to change the "name" attribute.
By polluting the name attribute and changing it to another name,
it's possible to falsify the value of the target field by the file body.

and, (This may not be relevant at all)
Spring was vulnerable due to the processing of Content-Disposition Response-Header.
https://pivotal.io/security/cve-2020-5398

Patch:
https://github.com/spring-projects/spring-framework/commit/0583b334b46cf2a591c72c2708ee3d2ac5d2b58c

reflected file download (RFD) commentary:
https://www.blackhat.com/docs/eu-14/materials/eu-14-Hafif-Reflected-File-Download-A-New-Web-Attack-Vector.pdf

I don't think this problem affects Firefox.
However, I will add it as additional information just in case.

Comment 8

[motoyasu saburi]

This problem appears to have been fixed some time ago.
What do you think?

Will a CVE be issued?
And can it be published externally?

Comment 9

[Andreu Botella]

This was fixed in bug 1686765, as part of changing the multipart/form-data encoding to follow the HTML specification and to be compatible with Chrome and Safari. When I was working on that bug, and on the specification change that enshrined Chrome/Safari's behavior, I did not know that this was an open security bug, nor did I realize that the fact that double quotes were not escaped in Firefox's previous implementation could be exploited. But this issue has now been fixed since Firefox 90.

Comment 10

[:Gijs (he/him)]

(In reply to Andreu Botella from comment #9)

This was fixed in bug 1686765, as part of changing the multipart/form-data encoding to follow the HTML specification and to be compatible with Chrome and Safari. When I was working on that bug, and on the specification change that enshrined Chrome/Safari's behavior, I did not know that this was an open security bug, nor did I realize that the fact that double quotes were not escaped in Firefox's previous implementation could be exploited. But this issue has now been fixed since Firefox 90.

Thanks for the update. I've tried to update this bug accordingly. Dan, can you check if I've not missed anything and answer the reporter's questions in comment 8 about CVE/publishing?

Comment 11

[motoyasu saburi]

How is the progress here?
I understand busy, but I would appreciate your response.

Comment 12

[motoyasu saburi]

Is there a CVE issued for this Issue?

Comment 13

[Daniel Veditz [:dveditz]]

Is there a CVE issued for this Issue?

We did not consider it a security weakness in Firefox itself, although we acknowledge the fact that the inconsistency between different browsers and different servers could lead to security issues in the servers consuming this input. The spec was updated and browsers should be consistent these days, but servers might still have security problems that they need to patch if they don't correctly handle unexpected input from old browsers or intentionally malicious clients. We think the CVEs would have to be issued by those servers.