On Sun, 12 Oct 2025 at 14:50, Demi Marie Obenour <[email protected]> wrote: > Would it make sense to only allow ASCII characters that are not special > to the shell? I think Git should enforce this restriction, as such > usernames are very risky and unlikely in legitimate use-cases. OpenSSH > enforcing this would be even better.
It possibly makes sense for git to do this, but OpenSSH enforcing it is a can of worms, RFC 4252 (section 5) says: string user name in ISO-10646 UTF-8 encoding I discussed this with the OpenSSH maintainers a bit and it is hard to change this in a backwards compatible way. > > It is also worth pointing out that a mitigation (and defence for > > future similar issues) is to stop git from cloning repositories over > > SSH for submodules, this can be done with: > > > > git config --global protocol.ssh.allow user > > This should be the default, as SSH is authenticated and the clone could > have CSRF-like side-effects. The TOFU check protects here somewhat, but agreed, however this breaks backwards compatibility... There's also a fix for something I discovered in OpenSSH 10.0 related to this: * ssh(1): prohibit the comma character in hostnames accepted, but allow an underscore as the first character in a hostname. If you can get a user to accept a TOFU banner with a "," in it, you can potentially MITM other hosts with this. It depends on your DNS resolver libraries accepting a comma in hostnames (macOS and musl do for example, OpenBSD changed this several years ago due to something else I discovered). Arguably also low severity, but it may be possible to combine multiple low severity issues like this into targeted attacks, which is my main concern with this research. [...] > Would it make sense to provide an option to quote shell metacharacters > when expanding, or to simply forbid them outright? The latter would be > a complete solution. Yes, I think there is more defense-in-depth that could be done here, but we are at the point of diminishing returns, there's probably other more important things to focus on than this. I don't want to single out a particular vendor, but given the relatively arbitrary nature of CVSS scores I was interested to see Red Hat saying they won't patch this likely based on the scoring: > Red Hat focuses on fixing Vendor CVSS scores 7.0 and above. So if it’s below that threshold, it’s probably > not going to get a fix between releases. Hence deferred. (https://www.reddit.com/r/AlmaLinux/comments/1o28mdo/comment/nimmzbz/) David
