Bug 64866 - Too small Content-Length validation breaks SSTP
Summary: Too small Content-Length validation breaks SSTP
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.4.46
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2020-11-02 16:22 UTC by Karsten
Modified: 2020-11-02 19:44 UTC (History)
0 users

Patch that utilizes strtoull to validate Content-Length (1.12 KB, patch)
2020-11-02 16:22 UTC, Karsten
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Karsten 2020-11-02 16:22:32 UTC
Created attachment 37544 [details]
Patch that utilizes strtoull to validate Content-Length

Too small Content-Length validation breaks SSTP

We believe a recently added Content-Length check has started breaking SSTP connections.
Tunneling SSTP though httpd would work for us in httpd 2.4.39 but with httpd 2.4.46 we
see the following error in the logs:
  [core:debug] protocol.c(1395): AH10242: client sent invalid Content-Length (18446744073709551615): /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/

The SSTP spec (https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sstp/7e5b2134-b4bf-435a-85bf-bfe0313fd889)
specifies that a Content-Length of 18446744073709551615 (ULONGLONG_MAX) must be set on
all SSTP connections.

Commit 2efe92b51dc4c33c907c9b8c17cb5038aad8038c "core, protocol: reject invalid
Content-Length ASAP." (https://github.com/apache/httpd/commit/2efe92b51dc4c33c907c9b8c17cb5038aad8038c)
has added a Content-Length check that (inadvertently?) restricts the Content-Length to a
signed long. The commit calls ap_parse_strict_length that ultimately calls strtol to verify
the input. This will give an ERANGE error on ULONGLONG_MAX and thus prematurely end the

A possible patch (that replaces strtol to strtoull) is attached.

I should probably confess that we're using apache httpd as a reverse proxy for sstp with a custom written mod_proxy_sstp. Unfortunately the content-length check happens before mod_proxy_sstp gets called and so our mod is never called anymore.

We would be very grateful if the Content-Length check could be made more lenient again so
it will support protocols such as SSTP once more.

kind regards
Comment 1 Joe Orton 2020-11-02 16:56:25 UTC
"specifies that a Content-Length of 18446744073709551615 (ULONGLONG_MAX)"

What could possibly go wrong?

IMO, this is obviously deliberately invalid (and unsafe) use of HTTP, and httpd is correct to reject it.  The protocol should chunked bodies if you need to avoid specifying a C-L.  I'd suggest writing a lower level filter to handle this not-really-HTTP protocol.
Comment 2 Karsten 2020-11-02 17:28:37 UTC
In our defense:
- Strictly speaking RFC 2616 section 14.13 does allow ULONGLONG_MAX as a content-length.
- Version 3.4.39 did support it.
- The commit that broke it only says it wants to check for validation errors sooner in the code, not stricter. We therefore figured it was accidental that existing applications got broken.
Comment 3 Ruediger Pluem 2020-11-02 19:44:44 UTC
A little bit of a background: 
RFC 7230 which supersedes RFC 2616 defines no maximum number that can be specified in the content-length field (3.3.2), but in 9.3. it recommends to reject too large payloads (RFC 7231, 6.5.11) in order to avoid attacks.
The clength field in the request_rec struct has been of type long / apr_off_t for about 20 years. Hence it is sensible for httpd to reject larger content lengthes.
The type of the field could be changed, but not for stable versions. Hence this is not an option for 2.4.x.