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)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
