bin/60154: sha256 and related checksum utilities fail to escape filenames printed to a terminal

["arraybolt3%riseup.net@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60154
>Category:       bin
>Synopsis:       sha256 and related checksum utilities fail to escape filenames printed to a terminal
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 31 23:05:00 +0000 2026
>Originator:     Aaron Rainbolt
>Release:        10.1
>Organization:
ENCRYPTED SUPPORT LLC (Whonix)
>Environment:
NetBSD netbsd-test 10.1 NetBSD 10.1 (GENERIC) #0: Mon Dec 16 13:00:11 UTC 2024 mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
When using 'sha256 -c hashes-file', filenames present in 'hashes-file' will be printed verbatim to the terminal without escaping. This allows an attacker who can trick a user into downloading a hashes file and using 'sha256 -c' on it without checking its contents, can manipulate the user's terminal, or attempt to exploit terminal emulator vulnerabilities.

I recently reported a very similar issue to the GNU Coreutil smaintainers, who blocked the hole by escaping the output of sha256sum when running in "--check" mode more defensively. See https://github.com/coreutils/coreutils/commit/b3fe24213ee350835097cefa8d0154f78ffd9d67. Something similar may be usable here. If programmatic output parsing is a concern, perhaps this can only be done when stdout/stderr is connected to a (pseudo)terminal.
>How-To-Repeat:
In a terminal, run:

    printf 'SHA256 (\033[1;1H\033[0J\033[30m) = 0000000000000000000000000000000000000000000000000000000000000000' > mal
    sha256 -c mal

Upon running 'sha256 -c mal', the entire screen is cleared and the prompt becomes invisible, requiring one to blindly run 'reset' to recover it.
>Fix: