Re: Announce: OpenSSH 10.3 released

[Demi Marie Obenour <demiobenour () gmail com>]

On 4/6/26 02:20, Damien Miller wrote:
> On Fri, 3 Apr 2026, Demi Marie Obenour wrote:
>
> > >  * ssh(1): validation of shell metacharacters in user names supplied
> > >    on the command-line was performed too late to prevent some
> > >    situations where they could be expanded from %-tokens in
> > >    ssh_config. For certain configurations, such as those that use a
> > >    "%u" token in a "Match exec" block, an attacker who can control
> > >    the user name passed to ssh(1) could potentially execute arbitrary
> > >    shell commands.  Reported by Florian Kohnhäuser.
> > >
> > >    We continue to recommend against directly exposing ssh(1) and
> > >    other tools' command-lines to untrusted input. Mitigations such
> > >    as this can not be absolute given the variety of shells and user
> > >    configurations in use.
> >
> > Is it safe (from a shell injection perspective) to pass inputs that are
> > sanitized for character set, but otherwise untrusted?  For instance,
> > is it sufficient to limit usernames to ^[A-Za-z][A-Za-z0-9_-]{0,31}$
> > and domain names to valid host names [1]?
>
> Probably, but this is the essence of the problem as we see it: we can't
> know for sure whether this is safe, because we don't can effectively
> reason about what shell is in use (and thus what its metacharacters
> are) and what the user is doing with these characters in their
> configuration file.

What about using execve() directly for these commands, rather than a
shell?  That would break backwards compatibility for what I suspect to
be rare configurations, while fixing most of these injection problems.

> To make things harder, this isn't the full set of characters that
> appear in usernames. At least %, @, \ and / are relatively common
> too :(
\ cannot be used safely unless single quoted on POSIX shells.

> > Can one assume that in situations where entries come from an
> > untrusted source (such as AuthorizedKeysCommand), OpenSSH _does_
> > do such checking?
>
> The *Command options in sshd_config require that the user exist
> in the system password database, otherwise they will not be
> executed.
>
> It's still possible to shoot youself in the foot with these if you
> try hard enough though, e.g. if you've rigged NSS to allow arbitrary
> usernames with no character filtering, then there is the potential
> for shell injection if the admin has specified token expansion in
> a *Command directive.

Does NSS generally enforce some sort of validation?

> > [1]: No more than 254 bytes (plus optional trailing '.'), no leading '.',
> >      each '.'-delimited component must start and end with [a-z0-9], not
> >      be more than 63 bytes, and only have [a-z0-9-].
>
> This too would block some hostnames that people use frequently.
> As a trivial example, '_' is common in hostnames despite being
> strictly invalid. IIRC there are other more esoteric ones too.
>
> -d


-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature