You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have contacted the maintainer several times and have not received a response in six months,
so I will describe the details of the vulnerability here.
Summary
fuel (<= 2.3.1) is vulnerable to "multipart/form-data Request tampering" caused by Content-Disposition filename lack of escaping.
(fuel v3 is not affected)
fuel > core > DataPart.kt > [InlineDataPart, FileDataPart, BlobDataPart] > contentDisposition
contains a vulnerability that allows the lack of escape filename.
For field names and filenames for file fields, the result of the encoding in the previous bullet point must be escaped by replacing any 0x0A (LF) bytes with the byte sequence %0A, 0x0D (CR) with %0D and 0x22 (") with %22. The user agent must not perform any other escapes.
On the other hand, there is no clear requirement in the RFC.
Since filename is a field that may reflect user input values as they are, it may be used in attacks.
(For example, the value may be retrieved from a DB, or a parameter may be used directly.)
The name field is unaffected because it is often a fixed value specified by the developer.
My calculations CVSS (v3):
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
Score: 6.5
However, I think is that this is a limited problem and an example of CVSS not matching the actual risk.
For field names and filenames for file fields, the result of the encoding in the previous bullet point must be escaped by replacing any 0x0A (LF) bytes with the byte sequence %0A, 0x0D (CR) with %0D and 0x22 (") with %22. The user agent must not perform any other escapes.
Therefore, it is recommended that Content-Disposition be modified by either of the following
e.g.
Before
Content-Disposition: attachment;filename="malicious.sh";\r\ndummy=.txt
After
Content-Disposition: attachment;filename=""malicious.sh";\r\ndummy=.txt"
or
After
Content-Disposition: attachment;filename="%22malicious.sh%22;%0d%0adummy=.txt"
If a system uploads a file to another site after the system has performed Validation of the uploaded file,
Validation can be bypassed by rewriting the file as .txt during validation and .sh during transmission.
Tampering with hidden requests
For systems that proxy/forward received files to internal systems
There is a possibility of rewriting (overwriting) fields that are not visible from the outside by tampering with the name field.
Appending and tampering with file contents via CRLF Injection
@motoyasu-saburi Hey, thank you so much for the update on the vulnerability! I'm a little bit busy with my new project at the moment but I can take a look on the fix next week. If you have time, please also feel free to send PR. For v2, bug fix (and others that are not feature updated) will always be supported.
I have contacted the maintainer several times and have not received a response in six months,
so I will describe the details of the vulnerability here.
Summary
fuel (<= 2.3.1)
is vulnerable to "multipart/form-data Request tampering" caused by Content-Disposition filename lack of escaping.(fuel v3 is not affected)
fuel
>core
>DataPart.kt
>[InlineDataPart, FileDataPart, BlobDataPart]
>contentDisposition
contains a vulnerability that allows the lack of escape filename.
fuel/fuel/src/main/kotlin/com/github/kittinunf/fuel/core/DataPart.kt
Line 100 in 105d311
fuel/fuel/src/main/kotlin/com/github/kittinunf/fuel/core/DataPart.kt
Line 176 in 105d311
fuel/fuel/src/main/kotlin/com/github/kittinunf/fuel/core/DataPart.kt
Line 272 in 105d311
By exploiting this problem, the following attacks are possible
For example, this vulnerability can be exploited to generate the following Content-Disposition.
input filename:
generated header in multipart/form-data:
The tampering header
*.txt
to*.sh
.dummy=".txt"
) .The cause of this problem is the lack of escaping of the
"
(Double-Quote) character &CRLF (\r \n)
in Content-Disposition > filename.WhatWG's HTML spec has an escaping requirement.
https://html.spec.whatwg.org/#multipart-form-data
On the other hand, there is no clear requirement in the RFC.
Since filename is a field that may reflect user input values as they are, it may be used in attacks.
(For example, the value may be retrieved from a DB, or a parameter may be used directly.)
The
name
field is unaffected because it is often a fixed value specified by the developer.My calculations CVSS (v3):
However, I think is that this is a limited problem and an example of CVSS not matching the actual risk.
Comprehensive report on this issue:
https://gist.github.com/motoyasu-saburi/1b19ef18e96776fe90ba1b9f910fa714
Cause & Fix
As noted at the beginning of this section, encoding must be done as described in the HTML Spec.
https://html.spec.whatwg.org/#multipart-form-data
Therefore, it is recommended that Content-Disposition be modified by either of the following
e.g.
or
reference:
Golang escape code:
https://github.com/golang/go/blob/561a5079057e3a660ab638e1ba957a96c4ff3fd1/src/mime/multipart/writer.go#L132-L136
PoC
Create Kotlin Project
Edit gradle file
Use a logging server of your choice, etc.
(e.g. Python)
Run PoC code
View logging server
Request multipart/form-data > Part:
Impact
Attack Scenario:
For example, the following may be considered
Validation Bypass
Validation can be bypassed by rewriting the file as .txt during validation and .sh during transmission.
Tampering with hidden requests
Reference:
Relate RFC:
https://datatracker.ietf.org/doc/html/rfc2231
https://datatracker.ietf.org/doc/html/rfc2616
https://datatracker.ietf.org/doc/html/rfc5987
https://datatracker.ietf.org/doc/html/rfc6266
https://datatracker.ietf.org/doc/html/rfc7578
https://datatracker.ietf.org/doc/html/rfc8187
WhatWG HTML Spec > multipart/form-data escape requirements:
https://html.spec.whatwg.org/#multipart-form-data
Golang Impliments:
https://github.com/golang/go/blob/561a5079057e3a660ab638e1ba957a96c4ff3fd1/src/mime/multipart/writer.go#L132-L136
Symphony (PHP Webframework) Impliments:
https://github.com/symfony/symfony/blob/123b1651c4a7e219ba59074441badfac65525efe/src/Symfony/Component/Mime/Header/ParameterizedHeader.php#L128-L133
Spring (Java Webframework) Impliments:
https://github.com/spring-projects/spring-framework/blob/4cc91e46b210b4e4e7ed182f93994511391b54ed/spring-web/src/main/java/org/springframework/http/ContentDisposition.java#L259-L267
Similar problem with another HTTP Client:
OWASP ASVS v5 > Content-Disposition escape disscussion:
OWASP/ASVS#1390
The text was updated successfully, but these errors were encountered: