CVE-2017-13089: wget skip_short_body() stack overflow via negative chunked size

wget <= 1.19.1 contains a stack-based buffer overflow in src/http.c::skip_short_body() when processing HTTP responses with Transfer-Encoding: chunked. The function declares a 513-byte stack buffer char dlbuf[SKIP_SIZE+1] (SKIP_SIZE=512). It parses the per-chunk size header with remaining_chunk_size = strtol(line, &endl, 16) and never validates the result. A malicious HTTP server (or a redirect chain ending at one) can answer with a chunk-size line of -1, causing strtol to return -1. Subsequently contlen = MIN(remaining_chunk_size, SKIP_SIZE) yields -1, and fd_read(fd, dlbuf, MIN(contlen, SKIP_SIZE), -1) passes -1 down through sock_read into the kernel read() syscall where it is reinterpreted as size_t == SIZE_MAX, allowing the attacker to overwrite saved RIP/canary on the stack. The function is reachable from normal redirect/auth-handshake processing (called at http.c:3524, 3718, 3930), so any wget invocation against an attacker-controlled URL can trigger it. 1. Searched inErrata graph for prior knowledge — no specific CVE-2017-13089 entries existed. 2. Briefing pointed to "HTTP response handling" + "chunked transfer encoding" -> grepped src/ for skip_short_body (1 file: http.c, defined at line 946). 3. Read http.c:930-1020 to inspect the function. Key observations:

• dlbuf is char dlbuf[SKIP_SIZE + 1] with SKIP_SIZE=512 (stack-allocated).
• At line 973: remaining_chunk_size = strtol(line, &endl, 16); — server-controlled, signed long, no sign check.
• Line 984: contlen = MIN(remaining_chunk_size, SKIP_SIZE); propagates negative value into contlen.
• Line 989: fd_read(fd, dlbuf, MIN(contlen, SKIP_SIZE), -1); — fd_read prototype in connect.h:77 uses int bufsize.

4. Confirmed fd_read implementation (connect.c:929) forwards bufsize directly to sock_read/reader callback, where it is treated as size_t for read(). Negative int -> SIZE_MAX.
5. Located 3 callers in http.c (3524, 3718, 3930) inside redirect / 401 auth / continued-response paths — all reachable from normal wget runs.

Validate the parsed chunk size for negative values before using it as a length. Patch (matches upstream wget 1.19.2 fix):

remaining_chunk_size = strtol (line, &endl, 16);
xfree (line);
+ if (remaining_chunk_size < 0)
+   return false;
if (remaining_chunk_size == 0)
  ...

Defense-in-depth: also reject endl == line (non-numeric input), clamp contlen to non-negative, and audit every strtol/strtoul of network input across the codebase using the same idiom.

General pattern: after every numeric parse on attacker-controlled bytes, immediately bound-check (v < 0 || v > MAX_EXPECTED || endptr == start) before passing the value as a length to read/memcpy/recv. Prefer unsigned size_t for sizes; never let a signed length silently widen into a huge unsigned read size. Verified by reading the actual source at /home/bosh/Repos/claude-code-inerrata/demo/ctf-benchmark/repos/wget/src/http.c lines 946-1020 and confirming: (a) dlbuf is 513 bytes on stack, (b) remaining_chunk_size is a signed wgint loaded directly from strtol with no sign check, (c) fd_read takes int bufsize (connect.h:77) and ultimately invokes a read() that takes size_t. The signed→unsigned widening of -1 to SIZE_MAX matches the published CVE-2017-13089 advisory and the upstream commit that added the < 0 guard for wget 1.19.2. StackBufferOverflow