masscan version/commit: current master, commit 94e118ccd26c2fb263fb2fe731043f7b3240723c
Build: make CC="clang -g -O1" (plain debug build, no sanitizer needed to reproduce)
OS: Linux x86_64 (Ubuntu 22.04 container)
Summary
A malformed -c configuration file causes masscan to crash with SIGBUS
inside realloc(). The crashing pointer is not garbage from an
uninitialized read, it contains literal bytes copied from the config
file, which means something in the config-parsing path is overwriting a
real pointer (likely struct RangeList.list / a Masscan-related struct
field) with attacker/user-controlled input before it's passed to
realloc.
Backtrace
Program received signal SIGBUS, Bus error.
#0 __GI___libc_realloc (oldmem=0x207331203d203a3a, bytes=24) at ./malloc/malloc.c:3426
#1 REALLOCARRAY (p=0x207331203d203a3a, count=<optimized out>, size=8) at src/util-malloc.c:21
#2 rangelist_add_range (targets=..., begin=117440519, end=336199692) at src/massip-rangesv4.c:320
#3 massip_add_target_string (massip=..., string="7.0.0.7-020.10.0.12") at src/massip.c:87
#4 masscan_set_parameter (masscan=..., name="range", value="7.0.0.7-020.10.0.12") at src/main-conf.c:2736
#5 masscan_read_config_file (masscan=..., filename="crash.conf") at src/main-conf.c:3920
#6 masscan_command_line (masscan=..., argc=4, argv=...) at src/main-conf.c:3337
#7 main (argc=4, argv=...) at src/main.c:1639
0x207331203d203a3a decodes as the ASCII bytes " s1 = ::" it is
literal text from the config file sitting where a heap pointer is expected,
confirmed by feeding it back into realloc/REALLOCARRAY in
rangelist_add_range.
How to reproduce
git clone https://github.com/robertdavidgraham/masscan.git
cd masscan && make
./bin/masscan -c crash.conf --echo
crash.conf (trimmed to the relevant lines ):
rate 1
ports = i:53
router- = 80
ports = i:5%
router- = = 1
ports = i:53
rr-1
ports = i:
ports = o:53
range=7.0.0.7-020.10.0.12
...
Result:
[-] CONF: bad MAC address: router- = 80
[-] CONF: bad MAC address: router- = = 1
Bus error (core dumped) # exit code 135
I generated the crashing config via AFL++ fuzzing of masscan -c @@ --echo
using a small seed corpus of valid config files
Expected behavior
A malformed configuration line should produce a parse error (as it already
does for some malformed fields, e.g. "bad MAC address" above) and exit
cleanly, not corrupt a heap-management structure and crash.
A note on scope
I saw in VULNINFO.md that the security-bounty process is scoped to remote
vulnerabilities (a scanned target attacking the scanner), and that crashes
from bad command-line arguments are considered acceptable for a
root-privileged tool. This crash is triggered through a -c configuration
file rather than a raw CLI argument or a network response, so I wasn't sure
it falls under that scope. Either way, it seemed worth flagging since it's a genuine pointer
corruption rather than a clean input-validation error.
masscan version/commit: current
master, commit94e118ccd26c2fb263fb2fe731043f7b3240723cBuild:
make CC="clang -g -O1"(plain debug build, no sanitizer needed to reproduce)OS: Linux x86_64 (Ubuntu 22.04 container)
Summary
A malformed
-cconfiguration file causes masscan to crash with SIGBUSinside
realloc(). The crashing pointer is not garbage from anuninitialized read, it contains literal bytes copied from the config
file, which means something in the config-parsing path is overwriting a
real pointer (likely
struct RangeList.list/ aMasscan-related structfield) with attacker/user-controlled input before it's passed to
realloc.Backtrace
0x207331203d203a3adecodes as the ASCII bytes" s1 = ::"it isliteral text from the config file sitting where a heap pointer is expected,
confirmed by feeding it back into
realloc/REALLOCARRAYinrangelist_add_range.How to reproduce
crash.conf(trimmed to the relevant lines ):Result:
I generated the crashing config via AFL++ fuzzing of
masscan -c @@ --echousing a small seed corpus of valid config files
Expected behavior
A malformed configuration line should produce a parse error (as it already
does for some malformed fields, e.g. "bad MAC address" above) and exit
cleanly, not corrupt a heap-management structure and crash.
A note on scope
I saw in
VULNINFO.mdthat the security-bounty process is scoped to remotevulnerabilities (a scanned target attacking the scanner), and that crashes
from bad command-line arguments are considered acceptable for a
root-privileged tool. This crash is triggered through a
-cconfigurationfile rather than a raw CLI argument or a network response, so I wasn't sure
it falls under that scope. Either way, it seemed worth flagging since it's a genuine pointer
corruption rather than a clean input-validation error.