go env is documented as outputting a shell script containing Go the environment:
$ go help env
By default env prints information as a shell script
(on Windows, a batch file). If one or more variable
names is given as arguments, env prints the value of
each named variable on its own line.
However, go env doesn't sanitize values, so executing its output as a shell script can cause various bad bahaviors, including executing arbitrary commands:
$ CC='$(echo shell expansion 1>&2)' go env | source /dev/stdin
shell expansion
Or inserting new environment variables:
$ CC=$(echo 'cc"'; echo 'OOPS="oops') go env
...
CC="cc"
OOPS="oops"
...
In general, if an attacker can set arbitrary environment variables on a system, they have better attack vectors than making go env print them out, but we still should be sanitizing the output here. Treating this as a PUBLIC track vulnerability because the scenarios where this results in a vulnerability are fairly artificial, and the correct fix is not immediately obvious. (Properly quoting values seems like an obvious fix, but shell quoting is subtle.)
This is CVE-2023-24531.
Thanks to Hunter Wittenborn (https://hunterwittenborn.com/) for reporting this issue.
go envis documented as outputting a shell script containing Go the environment:However,
go envdoesn't sanitize values, so executing its output as a shell script can cause various bad bahaviors, including executing arbitrary commands:Or inserting new environment variables:
In general, if an attacker can set arbitrary environment variables on a system, they have better attack vectors than making go env print them out, but we still should be sanitizing the output here. Treating this as a PUBLIC track vulnerability because the scenarios where this results in a vulnerability are fairly artificial, and the correct fix is not immediately obvious. (Properly quoting values seems like an obvious fix, but shell quoting is subtle.)
This is CVE-2023-24531.
Thanks to Hunter Wittenborn (https://hunterwittenborn.com/) for reporting this issue.