tests/01_engine-java.test

#!/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"
Fix three network-facing overflows in the FTP and Java parsers (#473) 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. Signed-off-by: Xavier Roche <roche@httrack.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com> 2026-07-02 21:54:01 +02:00			`#!/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"`