[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3b3e0ccd-0365-4383-8dba-8c195a15d7eb@gmail.com>
Date: Mon, 6 Apr 2026 19:12:31 -0400
From: Demi Marie Obenour <demiobenour@...il.com>
To: Damien Miller <djm@...drot.org>
Cc: oss-security@...ts.openwall.com
Subject: Re: Announce: OpenSSH 10.3 released
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)
Download attachment "OpenPGP_0xB288B55FFF9C22C1.asc" of type "application/pgp-keys" (7141 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (834 bytes)
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.
