Re: Announce: OpenSSH 10.1 released

[David Leadbeater <dgl () dgl cx>]

On Sun, 12 Oct 2025 at 14:50, Demi Marie Obenour <demiobenour () gmail com> 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