mirror of
https://github.com/xroche/httrack.git
synced 2026-07-03 07:33:49 +03:00
90e804a712
get_ftp_line() copied a server reply byte-by-byte into a fixed char[1024] with no index bound, so a hostile or MITM FTP server could smash the stack with an over-long CRLF-less line. Bound the write and truncate. The ftp:// userinfo parser copied "user:pass@" into user[256]/pass[256] with two unbounded loops, overflowing from a long userinfo supplied by a hostile ftp:// link. Extract the split into ftp_split_userpass(), which truncates each field to fit. The Java .class parser did calloc(header.count, sizeof(RESP_STRUCT)) on an attacker-controlled u2 count, allocating ~68 MB per crafted class (DoS). Cap the count to the file size (each constant-pool entry is at least one byte on disk) via a new hts_count_fits() guard, and move the alloc/free to the bounds-checked calloct/freet wrappers. Self-tests: ftp-line drives get_ftp_line over a socketpair with a 4 KB reply, ftp-userpass feeds an over-long userinfo, java exercises the count cap. The first two abort under ASan on the pre-fix code. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Xavier Roche <roche@httrack.com>
8 lines
189 B
Bash
Executable File
8 lines
189 B
Bash
Executable File
#!/bin/bash
|
|
#
|
|
|
|
set -euo pipefail
|
|
|
|
# .class constant-pool count is capped to the file size (calloc DoS).
|
|
httrack -O /dev/null -#test=java run | grep -q "java constant-pool cap self-test OK"
|