On Tue, 27 May 2025 at 14:43:44 -0700, Alan Coopersmith forwarded:
The vulnerability is exploitable when:
1. A user passes the key specification in traditional format (
+0.18446744073709551615R)
How would an attacker trigger this? Is this only exploitable if the
attacker has control over the sort key (equivalent of -k), *and* the key
is passed in to sort(1) via the traditional +POS syntax rather than the
POSIX -k option?
I ask because, if there's no reasonable scenario where this is
attacker-triggerable, then this would not be a security vulnerability
but instead just an ordinary bug (which of course is worth fixing, but
doesn't have to come with the urgency and overhead of dealing with a
security vulnerability). Assigning CVE numbers to ordinary bugs dilutes
their value for tracking genuinely exploitable vulnerabilities.
I would normally have assumed that sort(1) is meant to be resistant to
attacker-supplied input (stdin or the contents of the file(s) given on
the command-line), but not intended to be given untrusted and
potentially attacker-chosen options?
In particular, if an attacker can give sort(1) completely arbitrary
command-line options, then that's already an obvious arbitrary file
overwrite via the -o option - which I would consider to be sort(1)
operating as designed (not a vulnerability, it's only doing what its
documentation says it will do), and instead a vulnerability in whatever
higher-level component is providing it with attacker-chosen command-line
options.
Thanks,
smcv
