Leaks user passwords via parameter expansion of variables in command arguments and command substitution
Leaks user passwords via parameter expansion of variables in command arguments and command substitution.
Tests confirmed these were visible and persisted to externally via standard Crowdstrike agent configuration. Expectation is that these would also be visible to other logging software, malware, and unprivileged users running top or ps commands at the same time as the command execution, as they can typically read command arguments.
Observed cases involved launchctl asuser..., dscl /Local/Default..., security add-generic-password... where ${auth_local_password} is used directly in a command line, and not passed via fd/stdin.
softwareupdate ... on lines 7589 and 7597 also look problematic, but testing was not performed on macOS 12.
"Verbose mode" lines may also present the same issue as above, distinct from 295 and 210.
I am aware of these security limitations.
One, it's a bash script. The entire project would have to be completeley rebuilt as a native binary in order to access more secure frameworks for interacting with kechain and directory services. While this is possible, it's literally months of work.
Two, Apple does not provide a secure public API to interact with the software update framework. The only local mechanism provided by Apple is the softwareupdate command line. Further, the calls made to softwareupdate with "visible" passwords are necissary given the limitaions (and frankly janky behavior) of that command.
In short, even I was to spend hundreds of hours completley rebuilding super as a more secure native app. Only Apple can resolve the limitations in softwareupdate.
(As an aside, "Verbose Mode" does indeed echo out passwords for debugging, but it does not write them to the persistent super.log.)
I do appreciate this feedback, and I will leave this issue open... but even if super was a native app... until Apple improves softwareupdate there's nothing to fully midgate this risk.