GHSA-fwj4-72fm-c93g json
Under-validated ComSpec and cmd.exe resolution in Mutagen projects
published 3y ago modified 8mo ago also GO-2023-1758
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
### Impact
Mutagen projects offer shell-based execution functionality. On Windows, the shell is resolved using the standard `%ComSpec%` mechanism, with a fallback to a `%PATH%`-based search for `cmd.exe`. While this is the standard practice on Windows systems, it presents somewhat risky behavior.
Firstly, `%ComSpec%` could, in theory, be set maliciously. Unfortunately, there's not much that can be done to prevent this attack surface, because `%ComSpec%` is the official mechanism for shell specification on Windows. We can, however, validate that it points to an absolute path, which one would expect for a properly set value.
Secondly, a fallback to a relative `cmd.exe` path, resolved via `%PATH%`, could be risky. The risk is largely mitigated by changes in Go 1.19 and later, but prior to that a malicious `cmd.exe` could been resolved in the current working directory. To mitigate this issue, Mutagen now uses the `%SystemRoot%` environment variable (also validated to be an absolute path) to resolve `cmd.exe` in the event that `%ComSpec%` is not set correctly.
### Patches
The problem has been patched in Mutagen v0.16.6 and v0.17.1. Earlier versions of Mutagen are no longer supported and will not be patched. Versions of Mutagen after v0.18.0 will also have the patch merged.
### Workarounds
Maintain control of the environment variable settings on your system, in particular the `ComSpec` environment variable.
### References
More information on `%ComSpec%` can be found [online](https://en.wikipedia.org/wiki/COMSPEC).
More information on Go's `PATH`-based lookup changes can be found [here](https://go.dev/blog/path-security), [here](https://go.dev/doc/go1.19#os-exec-path), and [here](https://github.com/golang/go/issues/43947).
A [similar issue](https://github.com/python/cpython/issues/101283) that was addressed within the Python subprocess module also provides additional discussion.
Patch / fix
- go github.com/mutagen-io/mutagen 0.16.6, 0.17.1
Is GHSA-fwj4-72fm-c93g in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerAffected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| go | github.com/mutagen-io/mutagen | <0.16.6 >=0.17.0, <0.17.1 |
0.16.6 0.17.1 |
References
Sources
- GitHub Advisory GHSA-fwj4-72fm-c93g
- OSV GO-2023-1758
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.