On 4/6/26 19:27, Damien Miller wrote: > On Mon, 6 Apr 2026, Demi Marie Obenour wrote: > >>> 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. > > People definitely use shell constructs in `Match exec` and `LocalCommand` > so this would be quite a loss on the client side.
If OpenSSH knew what the shell was, could it quote appropriately? Presumably most people are using POSIX-compatible shells. > On the server-side, we already use execve(), but that's not a guarantee > of safety. As an extreme example, consider > > AuthorizedPrincipalsCommand sh -c %u That is true, but also presumably nobody is doing that :). >>> 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? > > Typically it's configured to perform a lookup in some database (e.g. > LDAP) and return only users that exist there. These are fine. > > Other configurations are possible, e.g. someone might naively create > a NSS configuration that accepted any username and returned default > account information for it. sshd isn't the only thing that might have > problems here. There's probably plenty of other things that would have > difficulty with getpwnam() returning valid user information for the > name "../../../../../../etc/shadow" Good point! -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
