Change #274407

Comments

http: reject chunk-size values that overflow wgint
* src/http.c (skip_short_body): Check overflow.
* src/retr.c (fd_read_body): Check overflow.

Both fd_read_body() (src/retr.c) and skip_short_body() (src/http.c)
parse the hex chunk-size line of a chunked-encoded HTTP response with
strtol() and only check the result for being negative.  strtol()
returns 'long', which silently clamps to LONG_MAX and sets
errno = ERANGE when the input overflows; that errno was never checked.

A malicious or compromised HTTP server can therefore send a chunk-size
line such as "FFFFFFFFFFFFFFFF" and have wget treat it as a chunk of
essentially unbounded size (up to LONG_MAX/INT64_MAX bytes) instead of
rejecting it as a malformed response.  As long as the server keeps
trickling bytes (each successful read resets the read-timeout), wget
will keep reading indefinitely, which is a remote denial of service.

Switch both call sites to str_to_wgint() (strtoll(), matching the
64-bit wgint type used to store the result on all platforms, including
those where long is 32-bit) and check errno for ERANGE in addition to
the existing negative-value check, clearing errno first so a stale
value cannot cause a false positive.

Verified with a fake HTTP server sending Transfer-Encoding: chunked
with a first chunk-size line of FFFFFFFFFFFFFFFF followed by a stream
of data: before the fix wget accepts the bogus size and keeps reading
everything sent to it as part of that single chunk; after the fix it
immediately aborts with Read error ... (Numerical result out of
range) instead of hanging.  Legitimate chunked responses continue to
be handled correctly, and the existing HTTP test suite (50 tests)
still passes.

Copyright-paperwork-exempt: Yes

Changed files

• src/http.c
• src/retr.c