[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAP9KPhAmmDiWjzig_bWEEN0y4d+y0gt58kXuowacpSTiE++2+Q@mail.gmail.com>
Date: Tue, 14 Oct 2025 10:43:43 +1100
From: David Leadbeater <dgl@....cx>
To: Demi Marie Obenour <demiobenour@...il.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: Announce: OpenSSH 10.1 released
On Sun, 12 Oct 2025 at 14:50, Demi Marie Obenour <demiobenour@...il.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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
