sanitize transfer-encoding and reject malformed "chunked"#617
Conversation
addressing tinyproxy#616 (yet another instance of request smuggling)
|
@afldl is your frontier model of the opinion this fix is sufficient? |
There was a problem hiding this comment.
Pull request overview
This PR hardens tinyproxy’s HTTP/1.1 request handling against request smuggling (issue #616) by sanitizing and validating Transfer-Encoding so that malformed or ambiguous chunked values can’t bypass the existing CL/TE protections.
Changes:
- Replaces the old exact-match
Transfer-Encoding: chunkedcheck with an in-place sanitizer/parser that attempts to validatechunkedplacement. - Rejects malformed
Transfer-Encodingwith an HTTP 400 response. - Continues to strip
Content-Lengthwhen a valid chunked framing is detected (to prevent CL/TE desync).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
you are right |
|
I'd like to ask whether the issue described below qualifies for a CVE ID, and what (if anything) I should prepare before submitting a formal request. |
does that mean that the PR was classified as sufficient and RFC conform? would you mind running the test (with asan) you used in #616 again on this PR ?
if the previous iteration had one than i guess it's only logical this one gets one too
i'm not familiar with CVE submission processes, but i was of the impression it's pretty straight-forward. |
|
Verified the fix on PR HEAD (d95fc6d) with a real ASAN/UBSan build over real TCP — all four bypass vectors from #616 are closed, Content-Length is correctly stripped on the canonical chunked case, malformed/multi-coding values are rejected with 400, and the run is clean. Looks good to me — resolves #616. Thanks @rofl0r! |
addressing #616 (yet another instance of request smuggling)